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.

Oct 17, 2014

The Busy Coder's Guide to Android Development Version 6.1 Released

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 6.1, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!

This update:

  • Adds material to the advanced notifications chapter on how notifications work with Android Wear devices, including how to lightly customize your notifications to add more Wear-friendly features

  • Adds two chapters covering the Storage Access Framework, for how apps can consume and publish documents on Android 4.4+

  • Adds a new advanced databases chapter, including a section on how to work with full-text indexing and searching (FTS) on SQLite

  • Adds some material on WebView security issues

  • Updates the “Fused Location Provider” chapter to replace the deprecated LocationClient with the current (yet stubbornly undocumented) new API

  • Various bug fixes and miscellaneous improvements

In addition, all the samples were upgraded to use Gradle for Android 0.13 and add the stub Gradle wrapper files, enough to allow for easy import into Android Studio. However, always check the gradle-wrapper.properties file before importing anything into Android Studio, as there is always the chance that somebody has published material linking you to a hacked Gradle installation.

The exact timing of the next update is a bit indeterminate, as is typical around likely Google announcement times. Most likely, the next update will not be until early December, though I may try to rush out an update before then if the next production version of Android ships soonish.

If you are not a subscriber, you may wish to learn what the Warescription has to offer. The book, plus a year’s updates and other Warescription benefits, costs $45 (credit card/debit card/PayPal) or its equivalent in Bitcoin.

Oct 14, 2014

Predictions of Play Store Fallout

The recent changes to the Play Store terms of service, requiring physical addresses and imposing a service-level agreement (SLA) on support questions are not terribly surprising moves. Google is basically trying to get developers of paid/in-app purchasing (IAP) apps to “raise their game” and provide better support to buyers.

That being said, I’m not sure that Google thought this all the way through. This has the whole “frog/boiling water” trope written all over it: while developers had been putting up with more and more hassle from Google, this particular change appears to be enough to get some developers to jump.

Tactically, the Play Store might well shrink in size over the next 60 days, as developers pull apps from the store, or Google kicks them out for failing to abide by the revised terms. If I’m Apple, I’m hoping that some independent service reports such an event, then using my press contacts to make sure the tech media trumpets how Android developers are leaving in droves.

Strategically, though, I expect to see several things arise in the coming years:

  • More emphasis on agents: There should be a rise in firms that will serve as agents for app developers. These agents would license apps from developers and sell those apps on the Play Store and elsewhere, in exchange for a cut of the proceeds. These agents, in turn, would provide the physical point-of-presence and front-line SLA handling, delegating any “real” support questions to the developers.

  • Formation of developer cooperatives: Some agents will likely be scum, if for no other reason than middlemen tend to run the gamut from sensational to scum in other places. Hence, I expect one or more developer cooperatives to form, to help ensure that there is at least one non-scum middleman. These would be registered as businesses or non-profits and would serve as an agent for their members, filling the middleman role while being a bit more transparent and friendly to the membership. Cooperatives with significant traction in specific countries might offer additional member benefits akin to what you might get from other forms of associations, such as group health insurance in the US, with an eye towards helping individual and small business developers. It is possible that existing groups, like the App Developers Alliance, might morph into this role.

  • Rise in interest in other distribution channels: Individual developers frequently skip other distribution channels (Amazon AppStore for Android, BlackBerry World, direct distribution, etc.) as they are a bit of a headache. Agents will be more interested in those channels, as they are “force multipliers” for their catalog of licensed apps. This in turn should spur development of Play Services replacement frameworks, better instructions for writing apps that can be deployed in multiple channels at once, and so on.

  • Greater consolidation of developer power: Agents, whether they are independent firms or are developer cooperatives, will wield more power than will the individual developers they represent, just due to sheer mass. Whether that concentration of power will be sufficient to cause Google to start behaving more transparently will depend largely upon…

  • Legal action: From the EU competition commission to class action suits, I expect Google’s legal team to be busy. Other markets may sue to break the “most-favored-nation” status that the Play Store has on Android devices, attempting to drive Google to create an “app installer” API that developers could support and users could opt into to allow apps to have Play Store-like ability to install and upgrade apps. Greater transparency around apps being kicked out of the Play Store, better support channels from Google to developers, and the like will also be part and parcel of what legal action might try to improve.

Now, my skills at predicting the future are modest at best, which is why I write Android books and do not tell fortunes. However, these seem like probable responses to the recent Play Store moves.

Sep 29, 2014

Upcoming Conference Presentations: Samsung Developer Conference

I have one more event scheduled for this fall: the Samsung Developer Conference. I will be delivering a couple of presentations there, on optimizing memory and power usage within your apps. These presentations should be on November 14th, though the exact schedule has not yet been announced.

I don’t speak at many vendor-specific events. Where I do, I make sure that I speak on general Android development topics (albeit ones of relevance to developers targeting that vendor’s specific environment). My presentations at the Samsung DevCon are valid for all Android devices, not just the Samsung line.

Also note that I don’t accept speaker fees or other significant compensation for speaking at events. At most, I might ask for the event to pick up the cost of a hotel or flight, but not always, and in particular I am not receiving any expense reimbursement from Samsung for speaking at their event. I am simply serving as a freelance Android developer evangelist, to help Android developers be efficient and effective in their app development.

Sep 25, 2014

The Busy Coder's Guide to Android Development Version 6.0 Released

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 6.0, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!

This largely completes the Big Book Pivot of 2014, adding Android Studio coverage to all of the core chapters (including the tutorials) and some of the trails.

Along the way, this includes:

  • Adding build.gradle files for all projects

  • De-Sherlocking all projects, except those that are specifically demonstrating ActionBarSherlock

  • Removing the chapter on IntelliJ IDEA and replacing it with material more specific to Android Studio

This book update also:

  • Adds a chapter on the manifest merger process, with particular emphasis on Gradle for Android and how manifests from different sourcesets plus libraries combine to create the generated manifest for the app itself

  • Adds a number of small improvements to the core chapters, as part of a more thorough review of that material

  • Tweaks the tutorials, partly to deal with Android Studio issues, and other minor changes to improve the instructions

  • Various errata fixes

Updates should now return to their normal every-four-to-six-weeks cycle, emphasizing new APIs, tools, and the like. I am planning on three updates yet in 2014, with Version 6.1 due out in early October.

If you are not a subscriber, you may wish to learn what the Warescription has to offer. The book, plus a year’s updates and other Warescription benefits, costs $45 (credit card/debit card/PayPal) or its equivalent in Bitcoin.

Sep 03, 2014

Older Posts