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.

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.