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.

 •  0 comments  •  flag
Share on Twitter
Published on October 25, 2017 13:20
No comments have been added yet.