Random Musings on the Android 8.1 Developer Preview 1

Each time Google releases a new developer preview, I rummage through the API differences report and the high-level overviews, to see if there are things that warrant more attention from developers, with an emphasis on mainstream features that any developer might reasonably use. I also tend to emphasize things that may not get quite as much attention, because they are buried in the JavaDocs.

Today, we got a developer preview of a maintenance release. Hence, there is not all that much to muse on. That’s not always the case: last year’s 7.1 Developer Preview 1 was much bigger by comparison.

Still, some things have caught my eye.

Bigger Than You Might Think

The API overview calls out a variety of things, of varying levels of impact on ordinary developers. For example, unless you’re doing AI work, the Neural Network API (NNAPI) is unlikely to be of relevance.

What intrigues me the most is the change so that getText() on EditText returns an Editable. In truth, it always did, but now that’s the official return type, as opposed to the CharSequence interface. My hope is that this is a prelude to an official rich text editing component (because, trust me, writing one is a pain).

They finally added the ability to filter installs based on RAM, in the form of new <uses-feature> elements for android.hardware.ram.low and android.hardware.ram.normal. In particular, I would expect that the following would limit you to devices with “normal” system RAM (i.e., not Android One devices):

<uses-feature android:name="android.hardware.ram.normal" android:required="true" />

Ideally, you do not do this, so that your app is available to more devices. But, if you make heavy use of the NDK, or you use android:largeHeap="true", you might consider this <uses-feature> element, to ensure that you will have enough memory with which to work.

SharedMemory is somewhat disconcerting. The API overview says that it can create “anonymous shared memory that can be used by multiple processes or apps”. However, there is little discussion of security, and I worry that somebody will figure out how to hack into this.

Stuff From the API Differences Report

As usual, some interesting things showed up in the API differences report that did not “make the cut” for the API overview.

• The best thing is that we have an actual API level — 27 — rather than the usual gamesmanship around the API level.

• You can request that an activity should appear above the lockscreen and should turn the screen on, via methods on Activity (setShowWhenLocked() and setTurnScreenOn()) and what I think are counterpart attributes on the <activity> element in the manifest.

• You can ask the NotificationManager if a given NotificationListenerService implementation has been granted permission by the user to listen for notifications. My guess is that this was added so that apps with a NotificationListenerService know if their service should be in action. From a privacy standpoint, I suspect that we can find a way to use this to determine if any NotificationListenerService is enabled, in case your app wishes to behave differently in such situations.

• In addition to the low/normal-RAM features, there are two more new feature strings available to us. One, android.hardware.type.pc, is of particular interest to me, given my (failed) prediction around Android on the desktop. This feature string is basically for a desktop-style device, and the documentation says “Due to the larger screen, the device will most likely use the FEATURE_FREEFORM_WINDOW_MANAGEMENT feature as well.” Also, there is a android.hardware.wifi.passpoint feature string, to confirm that the device supports the Passpoint stuff in WifiManager.

• SQLiteDatabase has a new dedicated createInMemory() method to create a memory-backed database. We’ve had ways of doing that before, but this simplifies matters.

• SQLiteOpenHelper has setIdleConnectionTimeout(), which is “the maximum number of milliseconds that SQLite connection is allowed to be idle before it is closed and removed from the pool” (and I don’t fully grok the ramifications of that). SQLiteOpenHelper also has setLookasideConfig(), for configuring the behavior of SQLite’s “lookaside memory allocator”, for performance tuning.