Random Musings on the M Developer Preview: the Bad

As I noted in yesterday’s post, each time Google releases a new SDK platform, I putter around looking for changes and identifying things that developers should think about, either because they were not covered in the I|O presentations or high-level overviews, or because they may cause problems.

Here, we start to get into the potential problems.

That being said, this post covers “the Bad”, simply because Sergio Leone did not name his movie “The Good, the Moderately Disconcerting, and the Ugly”. Probably that would be too long for the movie poster.

So, what has me, um, moderately disconcerted?

The biggest area of concern is with the new app permission system. The increased user control over permissions is, on the whole, a Very Good Thing. I and others have been calling for this for six years. Allowing users to control what apps can do what, on a more fine-grained basis than before, is great. However, that does not mean that what is proposed is all unicorns and rainbows — there are issues for developers and users alike.

On the developer front, you’ll need to quickly “retcon” your app to assume that you do not have all the permissions you want, to ask for them on the fly, and to deal with rejection with grace and aplomb. That may or may not be easy to all get in place in the next few months, in concert with everything else you were planning on doing with your summer (or, in the case of the Southern Hemisphere, winter).

If you elect to ignore the new permission system, that’s fine, but now you wind up with App Ops-esque behavior. Dave Smith performed some early analysis and gives you an idea of what your “legacy” app should expect.

However, what Google giveth in terms of user control, Google also taketh away, at least in how the permissions are presently organized. The preview docs state:

When the user installs or updates the app, the system grants the app all permissions that the app requests that fall under PROTECTION_NORMAL. For example, alarm clock and internet permissions fall under PROTECTION_NORMAL, so they are automatically granted at install time.

The problem is, as a Redditor pointed out, that many of the existing normal permissions are things that the user really needs to know about, such as:

• the ability for the app to find out the user’s Gmail address (GET_ACCOUNTS)

• the ability for the app to find out the user’s (probable) phone number (READ_PHONE_STATE)

• the ability for the app to read external storage (READ_EXTERNAL_STORAGE), which we just got a year or so ago

• fuss with tasks (GET_TASKS, REORDER_TASKS) and background processes (KILL_BACKGROUND_PROCESSES)

• open and close the status bar (EXPAND_STATUS_BAR)

• and so on

Apps can request and get all of those capabilities without much in the way of user notice.

There are normal permissions in the SYSTEM_TOOLS permission group that really need to be better controlled, like WRITE_SETTINGS. Also, it is unclear what happens to dangerous permissions in permission groups that are not ones that the user can control via Settings, such as SYSTEM_TOOLS.

Now, at Google I|O, they indicated that an overhaul of these permissions, in terms of permission groups at least, was on the docket. Hopefully, it will cover these sorts of problems by the time M ships as Android 5.2/6.0/Turbo System 5000/whatever.

Here are some other things showing up in the first edition of the M Developer Preview that represent possible trouble spots:

• There are changes to ART that apparently break the Android Support package. There is a tiny note in the preview docs:

If your app uses the v7 appcompat library or the v7 recyclerview library, you must update your app to use to the latest versions of these libraries.

That’s buried deep in the preview docs, though, and many developers will miss it outright. I can only hope that the build tools will point out incompatibilities here, via Lint checks or the equivalent. Regardless, you should consider upgrading your appcompat-v7 and recyclerview-v7 libraries before M goes to production.

• The built-in edition of Apache’s HttpClient was deprecated in Android 5.1 and removed entirely for the M Developer Preview, though there are things you can add to your Gradle build files to re-enable it. I have no idea how you would re-enable it if you are not building via Gradle, though (e.g., Eclipse users). And this is going to cause no end of support headaches for those of us trying to help newcomer Android developers. I would have left it as deprecated for longer, unless there is a specific security concern, in which case it’d be neat if Google would mention such a concern. As I wrote in a previous blog post, if you need to continue using the HttpClient API, consider switching to OkHttp and their HttpClient compatibility layer, or consider switching to Apache’s separate Android edition of HttpClient. Otherwise, switch to HttpURLConnection or OkHttp’s native API.

• Google heavily touted “Now on Tap”, but that’s not shipping in the previews, so we have no idea what the default behavior will be with our apps and we cannot test the Assist API to try to manage that behavior. We also do not know what “the standard set of information that the platform passes to the assistant” means and whether there is any means to control that short of FLAG_SECURE. I am starting to contemplate recommending FLAG_SECURE as default behavior, to be opted out of for activities where you are really really sure that the user won’t mind other things peeking at.

UPDATE: A post on ProgrammableWeb suggests that “Now on Tap” will be accomplishing this via “the view hierarchy”. I would surmise that this means the accessibility APIs, with FLAG_SECURE simply serving as an indicator that Now really shouldn’t peek (Until Google decides to do that too. Because Google.).

• Google touted Chrome custom tabs, but it seems undocumented, and it is unclear if anything related to it is something that we would be able to test prior to M shipping for realz. UPDATE: Documentation is available at the Chrome Developer site, though this feature is only in the dev channel at the present time.

• Users can silence heads-up notifications. That’s fine, and I think there’s hooks in the API to find out that the user has done this, but it does mean that your heads-up notifications may not behave as you have been expecting from Android 5.0 and 5.1.

• “Adopting” removable storage will be useful for users, particularly of lower-end Android devices with limited on-board storage, as adopted removable storage expands internal storage. For Android development old-timers, android:installLocation is back in play. For newcomers to Android, you probably have not been thinking about android:installLocation and the ramifications of the user moving your app to removable media.

• Apps can now inject themselves into the EditText action mode, so they show up as an available option, by implementing an ACTION_PROCESS_TEXT activity. This has interesting possibilities, but I worry about overuse and lack of user control.

• There are signs that multi-window support is making it into Android, with various sites reporting ways that a firmware can be tweaked to enable this developer option. I sincerely hope that developers have access to a preview of this capability before it goes live, whether that is part of the M Developer Preview or some future developer preview.

• The regression from Android 5.1, where AlarmManager repeating events are limited to a minimum one-minute period, is still undocumented. Then again, the whole background processing area is FUBAR in the M Developer Preview, as will be covered in a blog post tomorrow.

• External storage has moved yet again. At least on the Nexus 9, adb users will find it in /storage/emulated/0.

• The AnalogClock widget has been deprecated, for the 37 of you still using it.

Tomorrow, I’ll start looking at stuff that is decidedly more ugly, starting with background processing.