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
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
<uses-feature> elements for
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
<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
setTurnScreenOn()) and what I think are counterpart attributes on the
<activity>element in the manifest.
You can ask the
NotificationManagerif a given
NotificationListenerServiceimplementation has been granted permission by the user to listen for notifications. My guess is that this was added so that apps with a
NotificationListenerServiceknow 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
NotificationListenerServiceis 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.passpointfeature string, to confirm that the device supports the Passpoint stuff in
SQLiteDatabasehas a new dedicated
createInMemory()method to create a memory-backed database. We’ve had ways of doing that before, but this simplifies matters.
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).
setLookasideConfig(), for configuring the behavior of SQLite’s “lookaside memory allocator”, for performance tuning.