What would be helpful is a tool that will fill in the missing part if I had some broken dollar bills... Broken accidentally, of course.

I would be very surprised if the European Commission accepts these terms.

*proceeding

Because of the hypocrisy of stating they are the "better choice", worth paying a premium for, and then processing to retain the "I paid a premium as a symbol of status" as the only real differentiator.

Orwell was prophesizing when he adscribed Britain to the Oceania block (including the American territories) rather than the Eurasia one.

Where did Status Nadella come from. Now it's the time for a "our platform is on fire" memo and Microsoft being acquired at sale price by that former employer.

Then, of it's made from wood...

It's a witch!

Let me know when they get to the 30 MW mining laser. Then I can go harvesting some asteroids.

Now just don't bother me until they discover an UNKNOWN one.

Pr0n! Anywhere! Anytime!

The J2ME security model did this. You would start a photo-manager midlet and you would have to authorize access in a nagging pop-up form for each single directory in the path to the photo you were going to see and then for the photo file itself. This was totally horrendous, and I prefer the security model in Android to that.

Moreover, it's difficult to make any automated system *understand* what a program is actually doing. If you just give permission to an app for connecting to a specific server for downloading the weather forecast, it could be using that same connection to funnel any data (for which it has access) away.

The more interesting approach to actually controlling access in a useful way is the way in which intents work in Android, actually. See Locale, for instance, for which you can get plugins downloaded as independent apps. The main program and the plugins communicate via a well-defined intent-based protocol. Each plugin will get different (and thus limited) permissions, as they need. The location plugin will access the GPS, a messaging one might need SMS or account access. You can enable/disable/install/uninstall them as needed, providing fine and sensible control.

To some extent, the same thing happens with the share menu, at a much more coarse level.

If you have rooted the device, you can intercept any communications through any of the operating system provided services, either by using the monitoring facilities it provides or by modifying it. You don't need to sniff the packets 'on air', and thus you can pick the traffic for bluetooth too.

If you are worried that sensitive data is transmitted over a network link... uhm... then the software should be encrypting the data.

I don't get what's your worry, anyway, other than people reverse-engineering Microsoft's protocols and creating alternative SmartGlass clients.

A 16 bit session id should be enough for everyone...

Most of the time Android activity screens just "stack" as they are being opened. An example with the GMail client would be InBox -> Display specific message -> Reply.

Usually, when you press the back button, you just cancel the top activity screen, popping it out of the stack. For instance, you could cancel replying to a message by pressing the back button, so that you get back to having the display specific message activity on top.

When backing/popping the last activity, the application is not needed anymore and usually its execution ends, taking you back to either the home screen or the "other" application that launched it (for instance, by choosing to share a photo via GMail from the Gallery application, you got a Gallery stack starting a nested GMail stack). This is different from pressing the home button, that just puts the activity stack aside (it's still open in the background while memory allows), so that you can "start another stack", and then switching back to the previous stack afterwards by holding home and then selecting the previous stack from the list of "currently active" stacks.

See this blog post to understand why the notification icon is needed:

Services can further negotiate this behavior by requesting they be considered "foreground." This places the service in a "please don't kill" state, but requires that it include a notification to the user about it actively running. This is useful for services such as background music playback or car navigation, which the user is actively aware of; when you're playing music and using the browser, you can always see the music-playing glyph in the status bar. Android won't try to kill these services, but as a trade-off, ensures the user knows about them and is able to explicitly stop them when desired.

So if you want it to keep running as a background service to be able to receive incoming calls, this is the standard procedure. And I seriously think Android notifications are one of the best thought parts of the system.

Another thing is the inability to leave the application screen by pressing the back button (you can use the home button though, but that's so un-androidy...) You can force the application to quit completely via a menu option in one of the screens.