Slashdot Mirror

It's not like you can just slap Android onto screenless HW and expect it to work as intended.

"Screenless"? A game console has an HDMI output. Or did you mean "touch screenless"? Android has always had support for input events from up, down, left, right, and activate keys. These may be discrete keys on the device, a trackball, or the arrow keys and Enter on a Bluetooth keyboard. I imagine that a directional pad and primary button could generate these events, which would let the user use any focus-navigable application.

In addition, Android 4.4 on my Nexus 7 tablet supports a USB mouse through an OTG adapter. I guess in applications that don't specifically request controller mode, a Fire OS for set-top boxes could make the left stick move the mouse pointer and the right stick act as the scroll wheel.

It's not like you can just slap Android onto screenless HW and expect it to work as intended.

"Screenless"? A game console has an HDMI output. Or did you mean "touch screenless"? Android has always had support for input events from up, down, left, right, and activate keys. These may be discrete keys on the device, a trackball, or the arrow keys and Enter on a Bluetooth keyboard. I imagine that a directional pad and primary button could generate these events, which would let the user use any focus-navigable application.

In addition, Android 4.4 on my Nexus 7 tablet supports a USB mouse through an OTG adapter. I guess in applications that don't specifically request controller mode, a Fire OS for set-top boxes could make the left stick move the mouse pointer and the right stick act as the scroll wheel.

My phone is running software based on Android Open Source Project, and its not the official software.

You want source? Here.
http://source.android.com/

Uninformed or trolling?

Android is 100% open. Read and learn

Imagine all files and programs on my phone have labels on them.

There are that sort of thing, eg android sandboxes. However the problem is that when an application is installed it asks for access to more things than it rightly needs. End users just install it, without really being aware what the new application can do.

Meanwhile less big companies like TomTom get sued for infringement.

http://en.wikipedia.org/wiki/Microsoft_Corp._v._TomTom_Inc.

And HTC pay Microsoft a $5 license for every Android device

http://arstechnica.com/information-technology/2011/10/microsoft-collects-license-fees-on-50-of-android-devices-tells-google-to-wake-up/

Actually I'm surprised that Google doesn't have a formal license fee for Android. They could charge for a license that they'd guarantee would cover all patents. Some would go on the patents they know the rest would go to fighting patent lawsuits in the future.

E.g. suppose Google knows that most licensees for Android pay $5 in license fees. They set up Android Licensing Inc which offers a patent indemnity license for say $10 per device. If you pay the license Android Licensing Inc will fight patent violation lawsuits for you. They could build in a patent pooling clause too.

You'd also be free to take your chances. Of course it's debatable how many Android OEMS would actually go for this. The big ones - Samsung, HTC, Sony etc have already negotiated their own arrangements and would presumably not want to patent pool. The small ones probably take their chances and negotiate licenses as they need to.

Probably they missed their chance to do this back when Android was announced. If they set it up as an industry consortium with patent pooling and a board of directors that governed the standard they could have done this. Android doesn't actually work like that - Google license the base OS for free but Google Apps are licensed.

http://source.android.com/faqs.html#how-can-i-get-access-to-the-google-apps-for-android-such-as-maps

Someone discussed this here

http://pando.com/2012/01/28/how-google-can-save-android-close-it-license-it-swim-in-the-profits/

By licensing Android, Google could begin to extract even more money from smartphones--which, I thought, was the whole point of being in business.

Won't licensing Android turn phone makers away from Google's OS? That may have been a worry a few years ago, before manufacturers had committed to the OS. But now Google and major handset makers are stuck on the Android train. They've built their entire businesses around the OS, and many of their customers love it. And, anyway, phone makers know that Android isn't really free in the first place--not to Google and not to handset makers. In addition to the cost of developing the OS, Google has lately been spending billions on patents to protect it. Nearly every handset maker, meanwhile, has signed licensing agreements with Microsoft to settle patent suits. Estimates suggest that each copy of Android costs phone makers $10 to $15 in licensing fees to Microsoft. That's still a bargain--Windows Phone 7 costs $20 to $30 per copy.

So here's Google's opportunity: It could charge phone makers $10 per Android license, raising the total per-copy cost of Android to between $20 and $25. Sure, Samsung, HTC and others may balk, but what are they going to do about the added cost? Going to Windows would be more expensive and confusing to their businesses. As an inducement, Google could also begin settlement negotiations with Microsoft and other patent litigants to reduce Android's licensing costs. Given all this, phone manufacturers would stick with Android--and Google would make a killing.

The reason I think they won't do this is that Samsung sell most Android phones. There have always been hints that Samsung would fork Android for its own ends and I think if Google tried to make them

This is better than my other link, sorry:

Once installed on a device, each Android app lives in its own security sandbox:

The Android operating system is a multi-user Linux system in which each app is a different user.
By default, the system assigns each app a unique Linux user ID (the ID is used only by the system and is unknown to the app). The system sets permissions for all the files in an app so that only the user ID assigned to that app can access them.
Each process has its own virtual machine (VM), so an app's code runs in isolation from other apps.
By default, every app runs in its own Linux process. Android starts the process when any of the app's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other apps.
In this way, the Android system implements the principle of least privilege. That is, each app, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an app cannot access parts of the system for which it is not given permission.

However, there are ways for an app to share data with other apps and for an app to access system services:

It's possible to arrange for two apps to share the same Linux user ID, in which case they are able to access each other's files. To conserve system resources, apps with the same user ID can also arrange to run in the same Linux process and share the same VM (the apps must also be signed with the same certificate).
An app can request permission to access device data such as the user's contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All app permissions must be granted by the user at install time.

From: http://developer.android.com/guide/components/fundamentals.html

Programs can, of course, run at startup - otherwise all of your push-based applications and automatic realtime Craigslist searchers would be pretty sad.

http://developer.android.com/guide/topics/security/permissions.html

I'm not sure about iOS, but the Android SDK gives access to a excellent and easy to use crypto libraries, as well as a Keystore class to securely store any keys your App generates. Check out the Security Tips section of the SDK docs. I would assume iOS and Apple's SDK provide something similar. I would hope they do, anyway.

I'm not sure about iOS, but the Android SDK gives access to a excellent and easy to use crypto libraries, as well as a Keystore class to securely store any keys your App generates. Check out the Security Tips section of the SDK docs. I would assume iOS and Apple's SDK provide something similar. I would hope they do, anyway.

Android's SDK enables by default the obfuscation:

The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer. Because ProGuard makes your application harder to reverse engineer, it is important that you use it when your application utilizes features that are sensitive to security like when you are Licensing Your Applications.

ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode. Having ProGuard run is completely optional, but highly recommended.

• The device has to ship with Google Play Store. This rules out OUYA, Kindle Fire, and almost any 2.x device that isn't cellular (such as Archos 8th generation and several Chinese brands).
• I will grant that I don't yet know about Android to know whether the the procedure for "set[ting] up with the proper broadcast receiver and permissions" survives a device reboot. Ideally, as I see it, an Android app that supports GCM should run only enough to set up the GCM receiver at startup.
• A lot of applications are set up to poll servers operated by third parties that lack direct support for GCM. For example, an e-mail client might be communicating with an IMAP server that lacks GCM support. Or if the developer of such an application is expected to rent a server that polls the e-mail server on the user's behalf, how should the developer recover the cost of operating that server? And how comfortable will the user be with giving the user's e-mail password to the developer's server so that it can check the user's e-mail on the user's behalf?

• The device has to ship with Google Play Store. This rules out OUYA, Kindle Fire, and almost any 2.x device that isn't cellular (such as Archos 8th generation and several Chinese brands).
• I will grant that I don't yet know about Android to know whether the the procedure for "set[ting] up with the proper broadcast receiver and permissions" survives a device reboot. Ideally, as I see it, an Android app that supports GCM should run only enough to set up the GCM receiver at startup.
• A lot of applications are set up to poll servers operated by third parties that lack direct support for GCM. For example, an e-mail client might be communicating with an IMAP server that lacks GCM support. Or if the developer of such an application is expected to rent a server that polls the e-mail server on the user's behalf, how should the developer recover the cost of operating that server? And how comfortable will the user be with giving the user's e-mail password to the developer's server so that it can check the user's e-mail on the user's behalf?

Oh look, Android apps have to ask permission to access contacts -- you can choose not to install the app and LOOK AT THAT, the app is blocked from getting your contacts.

It never ceases to amaze me how utterly helpless iPhone users are, even better is how iPhone users who seem to love bashing Android can't seem to grasp something as simple as "If you don't want an app to access your contacts you shouldn't install the fucking app."

http://developer.android.com/reference/android/Manifest.permission.html#READ_CONTACTS

My question is why are you installing apps from developers you don't trust? Do you really trust your holy god Apple to not make any mistakes and there not be any sort of exploit that a developer can use to bypass the permissions system? If you don't trust the developer don't install the app to begin with. It's a dumbass security practice to install a virus on a computer, even if that machine is locked down...why do you insist on doing it with an iPhone?

"Mirrors phone screen on HDTV"

Does this work even in applications that turn on LayoutParams.FLAG_SECURE to disable screenshots, such as client apps for video rental services?

This isn't even a permission an App can request on Android. Not sure about iOS.

There is, actually. READ_HISTORY_BOOKMARKS

  To prevent apps from using this (and other permissions) download something like App Ops or root your device and use XPrivacy.

Actually, that's not true. According to the Android FAQ, you can use the source to create whatever you want. You cannot use the trademark, but you can use Android itself (through AOSP) to run on your hardware. This is why there are so many Android OEMs in China and such; they get to use the software for free and the only restriction is not showing the logo and not using the name.

The main reason why many OEMs don't do this, usually, is that it also precludes them from using Google Play services like Music and the store itself (which, frankly, is fair game; these are Google services maintained by Google, as such you're expected to pay them for that). There is however one extremely high profile example of an OEM doing just that: Amazon. The Kindle Fire does not use Google Play nor the Android branding and as such does not need to pay Google anything for it. The only possible cost is patent licensing (which would be there regardless).

Great idea but it's not exactly a secret that Google has a lot of trouble convincing carriers and OEMs to update their devices. Ordinarily, that would blunt the ability to fix problems and add features to existing devices but Google has an answer to that. Since Google can't convince carriers and OEMs to update their devices (apart from Google's own Nexus line), Google crafted a workaround.

If you have an Android device and you check your installed apps (make sure its on the All tab and not the Downloaded tab) you'll probably see an app called Google Play Services. If you check the permissions on this app you'll see it pretty much has the authority to do pretty much anything it wants. It can even alter its own permissions without notifying the user and updates itself silently without relying on the Play Store to do so. Ordinarily, this kind of God-like app would be creepy but Google has basically used it to bypass carriers and OEMs and push out new features without having to actually update the OS. Pretty much any device running Froyo (2.2) or higher uses this.

I wonder if Google actually needs to update the Android OS itself to fix bugs or if they can just use the Play Services app to work around this.

I think I'm qualified to comment on this. I've been an iOS developer since 2008. My company makes iOS and Android applications. I used flagship Android phones from 2008-2012 before switching to the iPhone. So I've had a lot of experience with both platforms from both the user and developer sides.

I think Android phones are terrible in comparison to iPhones. The reason why I started out with Android phones was for the reasons you outline - more open, and more flexible. I quickly discovered that wasn't all it was cracked up to be. The reason why I stayed with Android for so long was that a) I was holding out hope that it would be better in the long run and b) I wanted a hardware keyboard.

Open: Android is "open" in the "open cathedral" sense. It's very difficult to just jump in, make a few alterations, and see the changes running on your device. Practically speaking, it's not developed in an open sense in the same way most open source projects are. You could write a book about the implications this has and how it undermines the benefits open source normally provides.

Less hostile to develop for: not a chance. Yes, Apple have the ultimate say-so on what's allowed on the App Store. Yes, that's a big deal. But with Android, you have to contend with thousands of different models, each with their own shitty customisations that break things. We deployed an application last week for Android. It was finished weeks beforehand for iOS. Despite only having to target three recent Android tablets (it was an in-house project), each tablet was broken in different ways. iOS development is a breeze by comparison.

The problem with producing applications for the iPhone is Apple's policies. That's not a development obstacle, that's a policy issue. As we are a digital agency, all this really means for us is that we can say "Apple won't allow that" to clients when they ask for us to do something that Apple won't allow. And you know what? 99% of the time, it's when the client is asking for us to do something user-hostile.

The problem with producing applications for Android is development. The client asks for the feature, there's no intrinsic reason why it can't be done, but in practice you find that what should work and what does work on various devices differs radically.

Then there's the upgrade issue. I've done a lot of web development. Android is the Internet Explorer 6 of the mobile world. Masses of people don't upgrade, and more than a quarter of Android users are still on Gingerbread, released almost three years ago. It takes less than a year for about 95% of iOS users to upgrade to the latest version.

This isn't just a developer problem, it's a user problem as well. When I bought my last Android phone, it was a flagship Sony phone shipped with 2.3 that they had committed to upgrading to 4.0. That's the only reason I gave in and stayed with Android. The promise that I might actually stay up to date for once. Sure enough, they broke that promise. But they dragged it out for a year saying that they would do it. Meanwhile, the version of Android I was stuck on had a bug that rendered my SIP phone line useless.

You lose features too. Remember when OTA upgrades were an advantage over iOS? The year before iOS added that feature, I got an Android upgrade that took that feature away. It was a shitty vendor customisation. I had to use a buggy desktop application that crashed my computer to upgrade Android. When I switched vendors? Same thing, but with a completely different buggy desktop application.

Android's a mess. It was a mess for the fours years I was using it, with every single handset I tried, as I was hoping in vain for it to get better. It never got better, in fact the problems with the platform became more numerous over time. It's "openness" is an illusion and is not going to fix the problems it faces.

I disli

Android is licensed under the Apache Software License, Version 2.0* and GNU GPL Version 2.0 (the Kernel), for everyone and for free. The license is telling you: here is the code, do what ever you like. To compare that with the restricted Windows EULA or license that you have to buy for at least 3$ per phone** is very deceptive.

* Android Open Source Project License
** Windows Phone licensing cost revealed by ZTE: $23 – $30

and is all but impossible on mobile devices

Now you are just spreading FUD. LMGTFY

They have more specific details about Kit-Kat on the Developer site. https://developer.android.com/about/versions/kitkat.html#44-hce

If only there was a way to create a UI that was independent of pixel density, so that UI elements take up the same percentage of the screen...

Really? and there was me thinking it was precisely so they could win a case brought against them by Oracle which they did.

You're not informed about that case, which was precisely about Oracle thinking that Google didn't have permission to make their own implementation of the Java APIs without giving them money.

The reason they went their own way has nothing to do with the GPL (only OpenJDK is GPL'd and at risk of patent suits because Oracle refuse to grant it protection) and everything to do with ensure their project couldn't have terms dictated by Oracle.

A GPL project enjoys patent protection and can have no field of use restrictions by virtue of the GPL itself. As for the fact that Google dislike the GPL, hear it from themselves.

Android doesn't use the JVM, it uses the Java language however. They've also never said they don't care about Java compatibility. You just made that bit up, because you're trolling, or stupid.

It's not them who said that. Google have always said clearly that Android development is based on the Java language. When the Oracle vs Google case was going on, it was a lot of people here on Slashdot who were saying that Android makes no use of Java the language, and that Google didn't need to copy the Sun APIs because they didn't care about compatibility with a language that they did not use, and whose ecosystem they did not take any advantage from. Not that I support Oracle's crazy stance that APIs can be copyrighted, it's just that I can't stand knee-jerk reactions to defend a company.

If you had an Apple II, you had everything you needed to develop new software for it.

Looks like they used a Multics box at MIT. http://www.frankston.com/public/?name=ImplementingVisiCalc

Mobile phones and tablets have no such tools.

Really?
http://developer.android.com/tools/sdk/eclipse-adt.html
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/iOS_Simulator_Guide/GettingStartedwithiOSStimulator/GettingStartedwithiOSStimulator.html

Their operating systems are shit packed on top of shit

Rather subjective. They do quite a bit more than Apple DOS or MS-DOS ever did.

fiddly little distraction machines that function as brightly colored noisy little pets

Same as it ever was:
http://en.wikipedia.org/wiki/King's_Quest

a way to drain their parents' wallets by sending nonsense to each other 24 hours a day

Ever use a BBS back in the day?

the world-changing technology the PC made possible

The PC made computing accessible to commonfolk where it was previously the province of large institutions. Mobile continues this trend.

With the exception of FOSS, there hasn't been shit developed for any platform since.

We invented a new platform. Web Applications and APIs facilitated by cheap, commodity hardware have changed the nature of human communications and learning in the last 15 years.

distracted by Unity and HTML5 and Haskell and all the other flavors of proprietary dumbfuckery

Huh? None of those are proprietary. If a young person chose to learn about and use Haskell, I think they'd be well-equipped to learn quite a lot about how computers work.

As an Android user I've neither seen nor heard of an Up button, but thanks for throwing that non-event into the mix.

Your missing knowledge of the OS on your phone doesn't help your argument.
http://developer.android.com/design/patterns/navigation.html

And all this still magically happens without any prescription of how something should work by a 3rd party.

And yet that same link IS a prescription of how something should work. Official from Android. AND it makes my point about consistency too.

Killing three birds with one link. Nice!

Note Android doesn't do multiple users either.

Android does do multiple users. Finding devices that make use of it may be another matter (perhaps the Nexus 10 and/or Nexus 7?).

You mean the empty space on the left and right of the button on all iPhones that's essentially wasted? If the entire face of the phone was the screen and the phone relied exclusively on soft buttons then you'd have a point. But as it stands now, there could be buttons on either side. Look at the S4 for an example.

The space that is usually used for a navigation title and a secondary button?

Yes, totally wasted. It would be like if Android put a bar at the top of every app that had a navigation title and some sort of back button, with a secondary button. Maybe they would call it something like the action bar.

Oh wait, that's exactly what they do.
http://developer.android.com/guide/topics/ui/actionbar.html

Fallen at the first.

"Icons and dialogs are "flat" (similar to Windows 7, etc.)"
Like Android.

You clearly don't know what flat icons are. Here's the latest android.
http://www.android.com/images/restricted-profiles.png
These are NOT flat icons. Take a loo at the camera icon for the most obvious example. Simulated highlight and shadow is used to make the icon look 3D. Same goes for all the other icons.

Oh the Android Open Source Project, hosted by Google that is the base of the official release isn't open source?

You mean this AOSP (Android Open Source Project): http://source.android.com/

Can't believe some idiot of a mod actually modded your post up, lol. Only on slashdot.

    You're expecting too much.

    Android is just another embedded *nix. I'm happy that it's Linux. You shouldn't expect it to have a whole bunch of scripting languages, and unnecessary servers.

    With all that said, it is a functional embedded system, where you *do* have the ability. to extend it do to all kinds of neat things.

    They provided hooks to just about everything in Java. I'm not terribly delighted with that decision, but it's what they went with.

    For most purposes, play is their package manager. For the majority of users, they'll never open a terminal. I do 99% of my phone stuff through the happy little touchscreen. That's the nice interface provided.

    If you really want the CLI package manager, you'll find pm, which does just about everything you'd expect from a package manager.

    You can get Apache, Perl, and pretty much whatever else you want on there. Is it going to be like developing for an x86 server or desktop? Not really. It's a different platform.

    If you're going to be developing for distribution, and not just for yourself, I'd recommend about the Android way to do it.. If you're doing it yourself, grab a copy of Perl for Android, and enjoy.

    If you're going to complain, well, that's up to you. At least research it a little.

The latest Android requires 340MB of RAM and 0.5MB of flash.

You probably wrote "MB" instead of "GB" accidentally. That spec sheet says 512MB of flash.

Microsoft Windows 8 has mimimum requirements of 4GB of flash, 1GB of RAM, and a dual-core processor. The latest Android requires 340MB of RAM and 0.5MB of flash. Windows Phone is bloated, buggy, and an awful UI that cannot be changed (unlike Android where you can put any launcher, or indeed custom rom, instead).

People are not buying Microsoft Windows phones. The reason is that both the hardware and the software is inferior.

Phillip.

Android is not linux. It is closed source.

Liar, liar, pants on fire.

No the docs for android java are from google and quite different from those from Sun/Orcle
http://developer.android.com/reference/java/security/SecureRandom.html
compare to
http://http//docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

By default, instances of this class will generate an initial seed using an internal entropy source, such as /dev/urandom. This seed is unpredictable and appropriate for secure use.

http://developer.android.com/reference/java/security/SecureRandom.html

A seed is an array of bytes used to bootstrap random number generation. To produce cryptographically secure random numbers, both the seed and the algorithm must be secure.
By default, instances of this class will generate an initial seed using an internal entropy source, such as /dev/urandom. This seed is unpredictable and appropriate for secure use.

http://developer.android.com/reference/java/security/SecureRandom.html

No. The Dalvik Java documentation is by Google: http://developer.android.com/reference/java/security/SecureRandom.html

The flaw is with the OS (or at least with how the OS is intended to work), SecureRandom() on Android is supposed by default to use a cryptographically secure seed to initialize the PRNG (at least, according to the documentation. In fact, it's recommended on that documentation page not to seed it yourself). It does not do so, hence the security flaw.

Fortunately, it's extremely easy to fix, but it's still a flaw in Android.

It isn't programmer negligence in this case, it's the underlying Android implementation. The default constructor is supposed to seed the generator with secure entropy. Conversely, setSeed() is considered insecure and not recommended.

See SecureRandom

And the lack of support in Android(which iOS has btw) to figure out if you are on a phone or not, really hurts the user experience.

Unless your app actually needs to make phone calls, why should you care whether the device is capable of doing so? Not that that's a problem.

Start your re-education here old man:

http://developer.android.com/guide/practices/screens_support.html

http://mobile.tutsplus.com/tutorials/android/android-layout/

Developing for multiple different screen sizes is not that big of a deal, unless your brain is trapped in the printed-page analogy. Its been done this way for 20 years. In this day and age Its. just. not. a. problem.

Clearly the one who has no clue about the modern world is you.

Doesn't work, not because of Google but because applications developers do not use the platform API to backup and restore the data

What's new about the profiles is that now they can be restricted from certain apps or actions (with some granularity), for parental control.

Other new features include:

* Intermittent Wi-Fi scanning for location (saves battery)
* OpenGL ES 3.0 support
* Bluetooth 4.0 LE and AVRCP 1.3 support
* Autocompleting dialpad
* Virtual surround sound

There's more under the hood changes:

* SELinux MAC system support for the app sandbox
* Better WPA2 EAP and Phase 2 authentication support
* Hardware root of trust support
* Modular DRM support (e.g. allows 1080p Netflix)
* Hardware geofencing
* Media muxer and VP8 encoding
* And of course, further rendering and other optimisations

Still, it's no ICS or Key Lime Pie.

What's new about the profiles is that now they can be restricted from certain apps or actions (with some granularity), for parental control.

Other new features include:

* Intermittent Wi-Fi scanning for location (saves battery)
* OpenGL ES 3.0 support
* Bluetooth 4.0 LE and AVRCP 1.3 support
* Autocompleting dialpad
* Virtual surround sound

There's more under the hood changes:

* SELinux MAC system support for the app sandbox
* Better WPA2 EAP and Phase 2 authentication support
* Hardware root of trust support
* Modular DRM support (e.g. allows 1080p Netflix)
* Hardware geofencing
* Media muxer and VP8 encoding
* And of course, further rendering and other optimisations

Still, it's no ICS or Key Lime Pie.

http://developer.android.com/about/versions/jelly-bean.html#43-media This actually says that they created a modular framework that can be used to better implement DRM.

This is a decent code sample too:
https://code.google.com/p/adamkoch/source/browse/#git%2Fbitmapfun

From, here:
http://developer.android.com/training/displaying-bitmaps/index.html

(adam koch is an Android developer advocate at Google, and the code comes from the AOSP but is backported to use the support lib)

ActionBarSherlock fills this role pretty well already, even with some added features. But this is good stuff nonetheless. The support library has always been a great addition to the SDK. It really helps avoid writing ugly wrapper classes, or the really ugly old technique of using reflection for API levels. I would like to see them add more widgets though. Such as TimePicker, CalenderPicker, etc. Some support for ORM, and better handling of Fragments, instance states, data persistence and Loaders (less black box-y).

Still it is nice to see the support library progress march on.

These sound helpful too:

Media
- Added TransportMediator helper class to manage media transport control, such as play, pause, skip and other media actions.
-Added DisplayManagerCompat for managing display output to one or more device displays.

Other changes
-Added WakefulBroadcastReceiver helper class for implementing a common pattern of detecting a device wakeup event and passing work off to a Service while ensuring that the device does not go back to sleep before the handoff is complete.
-Added two new APIs, commitContentChanged() and rollbackContentChanged(), to AsyncTaskLoader to help deal with background updates for data changes that are subsequently canceled.

http://developer.android.com/tools/support-library/index.html

Details are a bit thin, and will presumably depend on the hardware; but Google has this to say:

"Android also now supports hardware-backed storage for your KeyChain credentials, providing more security by making the keys unavailable for extraction. That is, once keys are in a hardware-backed key store (Secure Element, TPM, or TrustZone), they can be used for cryptographic operations but the private key material cannot be exported. Even the OS kernel cannot access this key material. While not all Android-powered devices support storage on hardware, you can check at runtime if hardware-backed storage is available by calling KeyChain.IsBoundKeyAlgorithm()."

They don't explicitly say how the media DRM features are handled; but it would certainly appear that they've been busy supporting higher-than-kernel hardware mechanisms that would certainly have the capability to verify the system state and freak out if filthy 'owners' have the temerity to mess with the device.

(Google has also owned Widevine for some time now, a company that is studiously unhelpful about the details; but which, according to its patent portfolio and past press releases, has been doing set-top-box DRM for a while now, with a long list of chipset vendors on the client list. They have a lot of chatter about a 'Virtual Smartcard', which sounds software-like; but 'software' could include firmware baked into a system well below the level of being manipulated by the kernel, short of a successful attack against the firmware.)

That sounds,

That's all fine and dandy, but what I'm the absolute most stoked about is that action bar is now supported back to API 7 http://developer.android.com/reference/android/support/v7/app/ActionBar.html