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
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
gfxinfofor finding jank
However, a few things did not get much “press” from Google that are wins for developers and users:
Build.VERSIONnow has a
PREVIEW_SDK_INTvalue. 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.
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
Notificationthat 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.
StrictModecan 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.
Debugclass 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.
NetworkStatsManagercan give you access to historical network access statistics, without your having to track it yourself via
ActivityManagerallows 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
Intent, so you can arrange to save it off somewhere. Or, your app can have an
ACTION_REPORT_HEAP_LIMITactivity 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.
Need an extra hand with your Android app development project? CommonsWare can help — reach out for details!