Random Musings on the 7.1 Developer Preview 1
Each time Google releases a new developer preview, I try to talk about the changes that may not be obvious when reading the high-level descriptions.
That’s particularly important now, as we literally have no time to react to Android 7.1. While the development community only has this Developer Preview 1, 7.1 devices are shipping, in the form of the new Pixel phones. Every Android OS update has had bugs reported by the community, and 7.1 is unlikely to be an exception.
So, let’s see what’s in store.
Round Icon Oddities
For what feels like little end-user value, I worry that the round icons are going to cause above-average angst, due to the way that they were implemented.
The right answer, IMHO, would be that:
the round icons would be exposed via
PackageManager, as a distinct icon from the regular app icons, and that
the decision of whether to use the regular or round icons would be made by the home screen implementation, and potentially the user (via some setting in the home screen)
Neither of those appear to be true. There is nothing in
and related classes that exposes the round icon separately. Worse,
the decision of whether to use regular or round icons is not made
by the home screen, or the user, but rather by the device manufacturer
(or custom ROM developer):
When a launcher requests an app icon, the framework returns either
android:roundIcon, depending on the device build configuration.
Note that the documentation there has at least one bug: this is not limited to launchers. Any request for the app icon will return either regular or round depending on a hardware setting.
This means that, out of the box, home screens cannot specifically work
with regular or round icons, but simply “get what they get” from the
platform. With luck, the developer community will settle on some standard
<meta-data> elements, where developers can specifically point out
their regular and round icons, so home screens can go with one or the
other based upon decisions made by the home screen developer and user.
When you add your own round icon, be sure not only to test your home
screen look, but anywhere else that your app might be using its own
icon. In particular, rather than just referencing a resource directly,
you may want to use
getApplicationInfo().loadIcon(), to ensure
that you get the same icon that the rest of the system uses.
Also, when you start trying to set up round icons, Android Studio 2.2.2 will yell at you. Just pat your IDE on the head and move along.
Limits on Revising targetSdkVersion
The release notes indicate:
Once you publish an app with
targetSdkVersionset to 23 or higher, you can’t later publish a version of the app with a higher
versionCodethat targets 22 or lower. This restriction applies in alpha and beta channels as well as production channel.
I am not terribly shocked that they are imposing this constraint. It does suck from the standpoint of making tactical fixes for addressing bugs, as it removes one possible workaround from the toolbox.
Effects on Existing Bugs
Android 7.0 has an as-yet-unfixed bug where
services can get foreground priority without a visible
This appears to be fixed.
Also, at least one of
Dan Lew’s drag-and-drop bugs
was somewhat addressed,
reverting back to the original behavior for apps with a
targetSdkVersion below 24.
Since Android 7.0 still has the regression, though, this
7.1 change may make things worse.
Note that notification sounds are still messed up.
The app shortcuts
feature is supported by both the Google Now Launcher (available on the
Play Store) and the Pixel Launcher. Hence, more people will get access
to this capability more quickly. Static shortcuts (using the
<meta-data> element) in theory could work on pre-7.1
devices, since there is no strict API change. That does not seem to be
the case at the moment. Similarly, third-party home screens could
support static app shortcuts prior to Android 7.1, so this may be
something you want to opt into sooner, as there is potential for
more “bang for the buck”.
Note that when you create app shortcuts, you must provide an
android:action in the
<intent> element inside the
This is required even if the action string is meaningless
android:action="why.is.this.required") and will be ignored.
If you leave off this attribute, your app shortcut will not work.
There are four new
KeyEvent values, of the form
KEYCODE_SYSTEM_NAVIGATION_DOWN (plus equivalents for the other
three cardinal directions). It is unclear exactly what “system
navigation” means here. The description is “Consumed by the system
for navigation down”, which begs the question of when we might
KeyEvent for something that was already consumed.