Random Musings on the M Developer Preview: The Good

Each time Google releases a new SDK platform, I rummage through the API differences report, the new Build.VERSION_CODES entry, and the high-level overviews, to see if there are things that warrant more attention from developers, with an emphasis on mainstream features that any developer might reasonably use.

This time around, for the M Developer Preview, I am dividing up my random musings into a series of posts, named after the famous Sergio Leone “spaghetti Western”, “The Good, the Bad, and the Ugly”. In today’s post, let’s look at some stuff that is fairly clearly good for all parties.

Many items that fall in this category got attention in the M Developer Preview overview or in Google I|O presentations, such as:

• the data binding engine
• the Android Support Design library (at least, once it works)
• app linking (though I worry about no-connectivity scenarios)
• direct share
• better information from gfxinfo for finding jank

However, a few things did not get much “press” from Google that are wins for developers and users:

• Build.VERSION now has a PREVIEW_SDK_INT value. Normally, that will be zero, but when running on a device powered by a developer preview, it will be a positive integer indicating what revision of the preview the device or emulator is running. Google has indicated that they will ship updates to the M Developer Preview, and they might change method signatures on new APIs added to the preview. You can confirm that you are on a specific preview revision via PREVIEW_SDK_INT, so you can opt into preview APIs when running a specific revision.

• NotificationManager has a getAllNotifications() method. Despite the name, this returns information about the notifications that your app raised, not all notifications raised by any app. That being said, for the first time, we have an API that can tell us if a Notification that we raised earlier is still outstanding or not, without us having to try to track this information ourselves. In other words, Google is starting to add read capabilities to formerly write-only APIs.

• StrictMode can now warn you if you attempt to perform network I/O over an unencrypted socket connection. This will likely be prone to false positives, particularly for non-HTTPS protocols, but it is still worth trying, to help ensure that you are properly securing the user’s communications over the Internet.

• The Debug class has access to “runtime stats”, via methods like getRuntimeStat(). Right now, this is mostly reporting information from ART about garbage collection, but in the future it may be expanded for more stuff.

• NetworkStatsManager can give you access to historical network access statistics, without your having to track it yourself via TrafficStats.

• ActivityManager allows you to call setWatchHeapLimit() when running on an emulator (at least, I think that’s what “This API only work if running on a debuggable (userdebug or eng) build” means in this case). This sets a threshold of memory consumption for your process. If your process exceeds that threshold, a heap dump will be generated, so you can try to determine why your app is consuming so much memory. By default, the heap dump will be shared using an ACTION_SEND Intent, so you can arrange to save it off somewhere. Or, your app can have an ACTION_REPORT_HEAP_LIMIT activity and get the heap dump yourself, perhaps set up to only be part of your debug builds so the activity does not ship with your production app.

There are many more bits of goodness in the M Developer Preview, particularly for more specialized areas (e.g., better BLE scanning), and there are probably some tidbits that I have missed. Note, though, that this blog post is about the M Developer Preview, and things can change for better or worse by the time this ships “for realz” as Android 5.2/6.0/whatever.

Tomorrow, I will take a look at some stuff that, IMHO, is more of a “mixed bag” that showed up in the M Developer Preview.