Android 8.0: What You Should Worry About

Minimizing the Panic

The Slow Roll of 8.0

  • 8.0 will affect 1% of users by end of 2017, 15-20% by end of 2018
  • 2017 will feature disproportionate number of "power users"

Minimizing the Panic

"Focus, Daniel-san. Focus."

  • OMG my code's gonna break
  • OK, when ya gonna implement this thing that everyone else has?
  • Oh, hey, that's cool for users, cheap and easy for us
    • Normally, a reasonable amount of this
    • Android 8.0, not so much

Breaking Changes

Putting the O in OMG

  • Background service changes
  • Background location degradation
  • Implicit broadcast ban
  • Changes in app management
  • Changes with overlay windows
  • Changes with ANDROID_ID

Background Service Lifetime

We Can't Have Nice Things

  • Limited to "several minutes"... where "several" seems be "one"
  • After that, service will be stopped, akin to stopService()
  • Does not directly terminate your process, but dramatically increases the odds that it will terminate shortly
  • Affects targetSdkVersion 26... and anyone the user chooses to blame

Background Service Lifetime

The Workarounds

  • Foreground service
  • JobIntentService
    • On Android 7.1 and older, behaves like IntentService
    • On Android 8.0+, uses JobScheduler
    • Gives you a larger but undocumented window for work (10 minutes?)

Starting Services in the Background

For Those of You Inclined to Cheat

  • After the one-minute background service window, background services are stopped and cannot be started
  • There in part to avoid "ping-pong" way to work around background service limit
  • Also affects you if your app has never been in the foreground (e.g., ACTION_BOOT_COMPLETED)
  • Affects targetSdkVersion 26... and anyone the user chooses to blame

Starting Services in the Background: Workarounds

Meta-Cheats

  • startForegroundService()
  • getForegroundService() on PendingIntent
  • JobIntentService

Background Location Degradation

We Can't Know Where the Nice Things Are

  • While app is in the background, location updates will be sporadic
  • May be superfluous, as your ability to work in the background is limited anyway
  • Continuous location updates probably requires a foreground service

Implicit Broadcast Ban

Because Polling Is So Much More Efficient... Wait...

  • targetSdkVersion 26 apps cannot receive implicit broadcasts via manifest-registered receivers
  • Massive expansion of formerly uncommon limitation (e.g., ACTION_BATTERY_CHANGED)
  • Rationale: process churn
  • Select system implicit broadcasts are whitelisted, as are self-broadcasts protected by signature permissions

Implicit Broadcast Ban

The Workarounds: Receivers

  • If internal to your app, switch to an event bus
  • Find another way to get this information, via polling and JobScheduler
  • Use a foreground service and a dynamic receiver
  • Keep your targetSdkVersion below 26 until you can figure out a better workaround

Implicit Broadcast Ban

The Workarounds: Senders

  • If internal to your app, switch to an event bus
  • Use explicit broadcasts
    • Single peer app? Single explicit broadcast
    • Unknowable number of recipients? Manual fanout
  • Switch to some other API model that supports polling and JobScheduler

Detecting Package Changes

Because Polling... Didn't We Cover This Already?

  • ACTION_PACKAGE_ADDED and kin subject to implicit broadcast ban
  • Workaround: JobScheduler and getChangedPackages()

Installing/Removing Apps

Admitting There's More Than the Play Store

  • Users can now grant install/removal rights on a per-app basis
  • Mechanics
    • Request REQUEST_INSTALL_PACKAGES, REQUEST_DELETE_PACKAGES permissions
    • Invoke ACTION_INSTALL_PACKAGE, ACTION_UNINSTALL_PACKAGE as normal
    • Can call canRequestPackageInstalls() on PackageManager

Misc Breaking(?) Changes

On Stuff That I Try to Avoid Using

  • Floating windows (e.g., TYPE_SYSTEM_ALERT)
    • Now all devolve to TYPE_APPLICATION_OVERLAY
    • Cannot overlay "critical system windows" (e.g. IME)
    • User has system-generated notification to block these windows

Misc Breaking(?) Changes

On Stuff That I Try to Avoid Using

  • ANDROID_ID
    • Now per-user/per-app (or, more accurately, per sharedUserId)
    • Part of continued privacy moves, to block device-level identifiers

What Android 8.0 Users Will Expect

TL;DR: Not Too Much

  • Notification channels
  • Autofill
  • Your app not crashing horribly due to the aforementioned breaking changes
  • A pony

Notification Channels

500 Channels, Still Nothing On

  • New home for hardware requests (LED, vibration, etc.) and importance
  • Allow user to override those settings on a per-channel basis
  • Notifications raised in the context of a channel
  • Use channel groups if you have lots of channels
  • Idea: allow users to tailor notifications based on their perceived value

Mechanics of Notification Channels

Not That Bad, All Things Considered

  • On first run, define channels and groups... which you can never modify again
  • In Notification.Builder, supply channel identifier
  • Optional: link to ACTION_CHANNEL_NOTIFICATION_SETTINGS (e.g., from your app's settings)
  • Required for targetSdkVersion 26... but no default channel for older targets

Autofill

Oh, This Is Gonna Be Fun

  • Roughly analogous to equivalent feature in Web browsers
  • Pluggable autofill service providers, configured in Settings
  • User is prompted, after form finished, whether to save information for autofill
  • Later, offered opportunity to apply that autofill information in future forms

Autofill: Opting In

Come On In! The Water's Fine!

  • Apply autofill hints to fields that match specific roles (e.g, username, password, credit card number)
  • That's pretty much it

Autofill: Opting Out

Because Autofill Services Might Suck

  • Widget hierarchy: android:importantForAutofill="no" or "noExcludeDescendants"
  • Entire Activity 

  getWindow()
    .getDecorView()
    .setImportantForAutofill(View.IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS);

Autofill: Security

There Are Reasons Why I Am Worried

  • Autofill security is contingent upon well-written autofill service providers
  • Possible to leak private data to malicious apps
    • Limited if autofill service is well-written
    • Very simple if autofill service sucks
  • Details to follow

Questions?

https://commonsware.com/presos/andevconDC2017