Random Musings on the Lollipop SDK

With each Android release, Google issues an API differences report, outlining things that were added, changed, or removed in a new API level compared to the previous one. This time around, for Android 5.0 theirs is a diff against the “L” Developer Preview, which is mildly annoying. Ideally, the comparison would be with the last production release.

UPDATE: There is separate differences report for API Level 20 to 21 that is probably a better choice for most people. Hat tip to Mike Evans for pointing it out!

I always review this to see what’s different beyond the sorts of changes that get more disclosure, coverage in Google I|O presentations, etc.

A few months back, I reviewed interesting changes in the “L” Developer Preview. Some of that stuff has stuck around for the Lollipop release, and more stuff has shown up that seem worthy of mentioning.

Here is what I see of interest that is new to 5.0, over “L”, with deprecations marked in bold:

• While a compacting garbage collector was one of the hoped-for outcomes from the release of a production-grade ART, it looks that that is still a work in progress.

• Somebody is probably already writing malware to make use of the screen capture and screen sharing APIs. If my reading between the lines is accurate, any activity using FLAG_SECURE will not be captured, just as their thumbnails are not captured for the recent-tasks list. However, this is yet another reason to consider using FLAG_SECURE, either on your own or at user request via a setting.

• Those malware authors not working on the screen capture stuff are probably working on the screen pinning stuff, where apps can prevent the user from leaving their apps. While this, like the screen capture stuff, requires users to agree via a pop-up dialog, way too many users are likely to just say “yeah, um, whatever” and get screwed. And, if the documentation is accurate (and it’s probably not), to escape, the user has to press and hold BACK and RECENTS… but RECENTS is hidden and therefore cannot be pressed. Joy.

• Neither the screen capture/sharing stuff nor the screen pinning stuff require any permissions. Nor do they require the double-opt-in pattern we have seen with things like DeviceAdminReceiver, NotificationListenerService, etc. Instead, they just require tapping on a dialog to accept. As a result, users have no way of knowing, before installing an app, whether the app will try to do any of these things.

• Google not only is offering a new Camera2 API, but they deprecated the original Camera API. I have no clue what I am going to do with my CWAC-Camera library…

• The API overview says that “a new system-managed processing thread called RenderThread keeps animations smooth even when there are delays in the main UI thread”… with no other obvious documentation on the subject. It would be nice to know how this relates to our ways of checking for and fixing jank.

• I’m going to need to run some tests to figure out WTF the setAlarmClock() method is on AlarmManager.

• We now have a first-class PackageInstaller for installing apps. I am not completely clear on whether or not this is a good thing, as I do not see any discussion of security.

• Sticky broadcasts are now deprecated. There is no indication if there will be future changes to existing system-sent sticky broadcasts, like ACTION_BATTERY_CHANGED, but it is something to keep an eye out for in future releases.

Here are items that I reported previously for the “L” Developer Preview that still seem to be applicable to Android 5.0 (with light prose fixups):

• Action bar navigation, of all forms, is deprecated. This includes both action bar tabs and drop-down (“list”) navigation. It does not include the “custom view navigation” (e.g., browser address bar).

• Part of the reason for this is that the action bar is being pulled out into something more readily manipulable by us developers. Activity has a setActionBar() method, taking a Toolbar parameter. Toolbar basically looks like a simplified action bar and can be placed in arbitrary spots elsewhere in your view hierarchy, in contrast with the locked-to-the-top action bar.

• getRecentTasks() and getRunningTasks() on ActivityManager are now deprecated and will return a reduced result set on L and higher devices.

• BatteryManager now gives us the ability to directly access battery information, without having to fuss with registering a null receiver for ACTION_BATTERY_CHANGED, albeit via a somewhat clunky getIntProperty()/getLongProperty() API. Presumably, this is with an eye towards making ACTION_BATTERY_CHANGED be non-sticky, given the sticky broadcast deprecation mentioned above.

• bindService() now requires an explicit Intent, if your targetSdkVersion is set to 21 or higher.

• We now have getExternalMediaDirs(), which is a bit like getExternalFileDirs(), but represent directories that will be scanned by the MediaStore.

• A boatload of new stuff has been added to DevicePolicyManager for those of you using the device admin APIs.

• FragmentBreadCrumbs is now deprecated, for the six of you who were using that class. :-)

• There is a new LauncherApps class that helps simplify finding the relevant launchable activities. This is tied into the new managed profiles system.

• MediaStore has been augmented with MediaStore.Audio.Radio. It is largely undocumented, and so it is unclear if this is referring to streaming radio stations, classic broadcast radio (e.g., FM), or something else.

• The TOP_LEVEL_* patterns in Patterns are now deprecated, presumably reflecting the fact that the number of top-level domains is expanding rapidly.

• Android now has some amount of tracking of “power save mode”, with an isPowerSaveMode() on PowerManager and an ACTION_POWER_SAVE_MODE_CHANGED broadcast. Whether this is for OEM-specific modes or for some new common power save framework in Android, I cannot say.

• In what might be a first, something was “undeprecated”, specifically INSTALL_NON_MARKET_APPS on Settings.Secure, as it was moved back there from Settings.Global.

• WebSettings now lets you control mixed-content mode, referring to whether WebView should load insecure content from a secure origin.