Random Musings on the Android 6.0 SDK

Each time Google releases a new SDK platform, I rummage through the API differences report, the new Build.VERSION_CODES entry, and the high-level overviews (which are missing at the moment), to see if there are things that warrant more attention from developers, with an emphasis on mainstream features that any developer might reasonably use.

Android 6.0 extends what we had in the M Developer Preview. A quick scan indicates that most of my interests and concerns from the original M Developer Preview SDK are still there, so I recommend that you start by reviewing my original four(!) posts:

• Random Musings on the M Developer Preview: The Good
• Random Musings on the M Developer Preview: the Bad
• Random Musings on the M Developer Preview: the Ugly (Part One)
• Random Musings on the M Developer Preview: the Ugly (Part Two)

Beyond those, here are some things that I noted in the Android 6.0 SDK that either were not in the M Developer Preview or I glossed over back in June:

• A whole mass of permissions and permission groups were removed, not merely marked as deprecated. This should not affect your manifests, but if you were referring to the symbols in Java code, you’ll have to implement some workarounds. More importantly, any apps that use any of the removed permissions will need to determine what the right course of action is to be able to go forward with Android 6.0. The roster of removed permissions includes:

  ACCESS_MOCK_LOCATION
  ACCESS_SURFACE_FLINGER
  AUTHENTICATE_ACCOUNTS
  BRICK
  CLEAR_APP_USER_DATA
  DEVICE_POWER
  FORCE_BACK
  GET_TOP_ACTIVITY_INFO
  HARDWARE_TEST
  INJECT_EVENTS
  INTERNAL_SYSTEM_WINDOW
  MANAGE_ACCOUNTS
  MANAGE_APP_TOKENS
  READ_HISTORY_BOOKMARKS
  READ_PROFILE
  READ_SOCIAL_STREAM
  READ_USER_DICTIONARY
  SET_ACTIVITY_WATCHER
  SET_ORIENTATION
  SET_POINTER_SPEED
  SUBSCRIBED_FEEDS_READ
  SUBSCRIBED_FEEDS_WRITE
  USE_CREDENTIALS
  WRITE_HISTORY_BOOKMARKS
  WRITE_PROFILE
  WRITE_SMS
  WRITE_SOCIAL_STREAM
  WRITE_USER_DICTIONARY

• If you have been using ACTION_INSTALL_PACKAGE to ask the installer to install an app, and your targetSdkVersion is 22 or higher, you now must hold the REQUEST_INSTALL_PACKAGE permission. It is unclear if “22 or higher” is a typo or if this really was a requirement for Android 5.1 that perhaps was itself undocumented.

• PendingIntent now has a FLAG_IMMUTABLE option. This indicates that you do not want the extras in the underlying Intent to be modified by anyone invoking this PendingIntent. I can see this being very useful, from a security standpoint, in many PendingIntent scenarios.

• Several interesting new Settings screens are now accessible via Settings action strings. One that will get a lot of attention is ACTION_MANAGE_WRITE_SETTINGS, where users can indicate whether apps can write to system settings or not. If your app requests the WRITE_SETTINGS permission, you may appear on this list, and you can call canWrite() on Settings.System to see if you were granted permission. There is also ACTION_MANAGE_OVERLAY_PERMISSION, where users can control which apps can “draw over other apps” (chatheads?). It is unclear how apps get on this list — I would have expected it to be tied to the SYSTEM_ALERT_WINDOW permission (akin to the WRITE_SETTINGS scenario above), though if that is the case, it is not documented that I can see. UPDATE: An eagle-eyed developer noticed canDrawOverlays() in Settings, and so the SYSTEM_ALERT_WINDOW flow is akin to the WRITE_SETTINGS flow.

• Two other Settings actions pertain to “app standby” and the whitelist whereby users can grant your app the right to continue running normally even if you have not been used for a while. ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS leads to the Settings screen where users can generally toggle on and off who is on the whitelist, and ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS for apps to beg to be put on the whitelist. Note, though, that to use ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, you have to hold the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, though at present this is a normal permission and should be granted.

• Also related to the above are some methods on PowerManager. isDeviceIdleMode() indicates if the device has not been used in a while, indicating that we might drop into Doze mode soon, and apps in “app standby” status may also stop running. A broadcast (ACTION_DEVICE_IDLE_MODE_CHANGED) will go out when this status changes. isIgnoringBatteryOptimizations() will tell you if the user has indeed put you on the “app standby” whitelist.

• The “App Assist” stuff that powers “Now on Tap” has a modest amount of documentation, stemming from the new android.app.assist package, and the onProvideAssistData() method on Activity.

• BatteryManager now defines broadcast action strings for ACTION_CHARGING and ACTION_DISCHARGING. No word on whether these can be registered for in the manifest (as opposed to ACTION_BATTERY_CHANGED), though presumably they can, as that status should not flip too frequently. There is also a simplified isCharging() method to determine if the battery is charging or not.

• As part of the overhaul of the permission system, the concept of system or signature|system permissions are deprecated. Instead, we have a bunch of new protectionLevel flags that I am sure that a lot of folks who root devices will be experimenting with soonish.

• Pretty much the whole Browser provider has been removed. This, at least in theory, would allow you to access bookmarks and such from a browser. Other than the original AOSP Browser app, I am not aware of other browsers actually supporting this, and the fact that it is removed (not deprecated) is telling.

• StrictMode now supports detectResourceMismatches(). It is designed to catch places where the resource system would do conversions for you that you could avoid. The cited example is having an resource that you retrieve via a call to getInt() on a Resources object. While this works, it would be more efficient to have an int resource. detectResourceMismatches() will report these to you. I am rather surprised that the instrumentation for this does not swamp the performance savings from doing the conversion, but, hey, they didn’t ask me…

• TextView now offers greater controls over the line-break strategy and hyphenation, via XML attributes (android:breakStrategy and android:hyphenationFrequency) and corresponding accessors. Line-break strategies are: simple, high-quality, balanced, where “high-quality” is the only one that cites using hyphenation. Hyphenation strategies are: none, less-frequent, and standard. The default strategy for TextView is high-quality, while the default strategy for EditText is simple.

• WebView now offers support for HTML5 “MessageEvent” interfaces, by means of classes like WebMessage and methods like createWebMessageChannel() and postWebMessage() on WebView.

• Of interest to analytics folks is the new requestUsageTimeReport() method on ActivityOptions. This allows you to register a PendingIntent that, when invoked, will hand you a couple of extras containing information about how long the user used the app that you are launching.

• There are now hooks for dealing with “captive portals”, those aggravating interstitial pages that you encounter when you have to request access to a network at a hotel, coffee shop, etc. For example, ConnectivityManager has an activity action named ACTION_CAPTIVE_PORTAL_SIGN_IN, designed for apps to help users sign in (saved credentials, perhaps?). There is a CaptivePortal class that comes along for the ride.

• There are now hooks for apps to be able to request that users replace the dialer (presumably with their app), plus configure and switch to different phone accounts, as part of a beefed-up TelecomManager. Plus, the android.telecom package got substantially expanded, with hooks to all sorts of new capabilities through the TelecomManager. We have new classes regarding calls, conferences, gateways, phone accounts, and so forth.

• We finally get a type-safe implementation of getSystemService().

• MODE_MULTI_PROCESS was deprecated. This was a mode flag used for opening SharedPreferences to allow multiple proceses to read and write those SharedPreferences simultaneously. Mostly, this was to support having components run in separate processes via the android:process attribute. Sharing SharedPreferences between processes was always described as unreliable, and they are making that more official now by getting rid of support for it. As the documentation suggests, please use a real IPC API (broadcasts, ContentProvider, etc.) for communication between multiple processes that represent your app. Or, stick to a single process.

• We now have official support for round screens (see isScreenRound() in Configuration). Presumably, this is for Android Wear. Either that, or the Motorola Aura is making a comeback.

• Curiously, the Build.VERSION_CODES value is still M. It is unclear if this is a mistake (and MARSHMALLOW will show up later) or whether the new convention is to stick with the single-letter values. It also contains no significant JavaDocs, which is rather surprising considering that Android 6.0 is a major version update.