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.
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_SECUREwill 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
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
We now have a first-class
PackageInstallerfor 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.
setActionBar()method, taking a
Toolbarbasically 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.
ActivityManagerare now deprecated and will return a reduced result set on L and higher devices.
BatteryManagernow gives us the ability to directly access battery information, without having to fuss with registering a
ACTION_BATTERY_CHANGED, albeit via a somewhat clunky
getLongProperty()API. Presumably, this is with an eye towards making
ACTION_BATTERY_CHANGEDbe non-sticky, given the sticky broadcast deprecation mentioned above.
bindService()now requires an explicit
Intent, if your
targetSdkVersionis set to 21 or higher.
We now have
getExternalMediaDirs(), which is a bit like
getExternalFileDirs(), but represent directories that will be scanned by the
A boatload of new stuff has been added to
DevicePolicyManagerfor those of you using the device admin APIs.
FragmentBreadCrumbsis now deprecated, for the six of you who were using that class. :-)
There is a new
LauncherAppsclass that helps simplify finding the relevant launchable activities. This is tied into the new managed profiles system.
MediaStorehas 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.
Patternsare 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
ACTION_POWER_SAVE_MODE_CHANGEDbroadcast. 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
Settings.Secure, as it was moved back there from
WebSettingsnow lets you control mixed-content mode, referring to whether
WebViewshould load insecure content from a secure origin.
Interested in Jetpack Compose?
jetc.dev has a weekly newsletter of the latest articles, samples, and other details of Compose development!