Random Musings on the N Developer Preview 4

Each time Google releases a new developer preview, I try to talk about the changes that tried to creep in, and the changes that did not make it in.

The N Developer Preview 4 is only slightly different than the NDP3 predecessor. This is not surprising, as we “head into the home stretch” for an upcoming product release. There are some release notes, though not much is reported there. The biggest change is with the multi-window support, where they changed android:minimalHeight and android:minimalWidth to android:minHeight and android:minWidth. Watch for some gently-used imal strings to be sold on eBay shortly.

Regressions and Changes… Compared to Production Android or NDP3

Other than the aforementioned attribute changes, little has changed that would represent a regression.

(and there was much rejoicing)

Other Stuff in NDP4

There is a custom pointer API now in Android N, where you can override the standard mouse pointer on a per-View basis. For simple changes, use setPointerIcon() to specify the PointerIcon to use when the pointer is over that View. There are many stock PointerIcon styles to choose from (e.g., TYPE_CROSSHAIR), and you can supply your own (e.g., emoji). Custom widgets might elect to override onResolvePointerIcon(), to be able to provide different pointer icons for different portions of the widget. Unfortunately, they elected to go with the override approach rather than an OnResolvePointerListener that you might set or add, which limits flexibility.

There is an ACTION_WEBVIEW_SETTINGS action string that you can use, to bring up a dialog where the user can choose their WebView implementation. On a Nexus 9 with a freshly-flashed NDP4, the user can choose from the vast array of one option: Chrome Stable. Presumably, other options (e.g., dev channel?) will be offered in the future. It is unclear under what circumstances an app would want to display this dialog.

And nothing else leaped out at me as being new and exciting.

Bugs in NDP4

Many of the bugs that I reported previously are still outstanding, including:

The ACTION_INSTALL_PACKAGE problems seem better, though I am not completely certain if installing an app from a ContentProvider is working. Plus, the “working as intended” multi-window race condition apparently is still working as Google intended, if not as app developers might have intended.

Interested in learning Kotlin? Check out the Klassbook for Kotlin language lessons that you can run right in your browser!