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 PackageManager 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:icon or 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 targetSdkVersion set to 23 or higher, you can’t later publish a version of the app with a higher versionCode that 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 Notification. 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.

Other Curiosities

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 android.app.shortcuts <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 <shortcut>. This is required even if the action string is meaningless (e.g., 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 get a KeyEvent for something that was already consumed.