Every new Android version introduces changes and improvements. Even if you're targeting an older Android version in your application, you need to understand what is the trajectory that the OS in following to be prepared. This presentation is targeting the enterprise mobility developers.

1. EUROPE

2. Developer Session
What’s Different in
Android L, M, N, O
Darryn Campbell & Pietro Maggi
Software Experts

3. • Android Trends & Trajectory
• Android Lollipop
• Android Marshmallow
• Android Nougat
• Android ‘O’
Agenda
What’s Different in Android L, M, N, O

4. COMMON PATTERNS

5. There are some interesting patterns emerging as Android evolves:
• Notifications have undergone major (or at least noteworthy) changes in every
release from KitKat to ‘O’.
• Notifications feature heavily in enterprise use cases it becomes increasingly
complex to lock down what the user is able to control
• Pushes towards power saving, taking flexibility away from developers with
consumer end user battery life in mind
• Locking down your device becomes increasingly complex.
• E.g. More system apps to prohibit
Common Patterns & Trajectory
Controlling device access

6. ANDROID LOLLIPOP

7. • Introduced in API 21
• Google sample: https://github.com/googlesamples/android-JobScheduler
• Helps perform background work in an efficient way, especially networking
• For older devices, with GMS, GCM Network Manager provides efficient background
job scheduling
• https://developers.google.com/cloud-messaging/network-manager
• GCMTaskService is typically simpler to manage and more difficult to mess up than
JobService
Note that GCMTaskService is implemented using the JobScheduler API on Lollipop
and newer OS.
Android Lollipop
JobScheduler API

8. • Many enhancements to BLE between Android 4.4 and Android 5.0
• Addition of peripheral mode
• Support for Beacon or iBeacon packets
• Allows broadcasting of advertising packets (hardware permitting)
• Improved background scanning no longer prevents the device from sleeping.
• API backwardly compatible with KitKat
Android Lollipop
Bluetooth LE Matures

9. ANDROID
MARSHMALLOW

10. • Dynamic runtime permissions
• Doze mode
• Bluetooth changes
• Encryption & Adoptable storage
• Trusted & untrusted resets
• Enterprise Android: COSU support (Corporate-owned single-use)
Android Marshmallow
Behaviour changes affecting Enterprise

11. Targeting API 23+
If you target API level 23+, your application is not going to
have the dangerous permission granted at install time, but
it needs to:
• Check
• Request
• Fail gracefully if not permission is not granted

12. Targeting API 23+
When the user installs or updates the app, the system grants the app all permissions that the app requests that fall
under PROTECTION_NORMAL.
For example, alarm clock and internet permissions fall under PROTECTION_NORMAL, so they are automatically
granted at install time.
Some of the permission that are now granted automatically are:
1. GET_ACCOUNTS
2. READ_PHONE_STATE
3. READ_EXTERNAL_STORAGE
4. GET_TASKS, REORDER_TASKS, KILL_BACKGROUND_PROCESSES
5. EXPAND_STATUS_BAR

13. What if I’m targeting API level 22 or older?
The new permission system is not enforce at install time.
If the user install your application, like before, it gets all the requested
permissions. BUT.
If an user can go into the settings application, it can removes the
permissions.
Lock down the device looks like a good idea to me!

14. Reminder: adb install Needs -g To Auto-Grant Permissions
If your app has a targetSdkVersion of 23 or higher, and you are
installing the app via the command line, note that adb install has two
possible behaviors:
• Used normally, the app is installed without any runtime permissions
granted. This mimics a normal app install, where you have to ask
for the permissions at runtime.
• Used with the -g switch, the app is installed with all runtime
permissions pre-granted, as if the app had a targetSdkVersion
below 22. This can be handy for rapid testing, though it is not
indicative of what the user will see.
Source: https://commonsware.com/blog/2016/03/18/reminder-adb-install-needs-auto-grant-permissions.html

15. It’s all about the battery!
Source: https://www.bignerdranch.com/blog/diving-into-doze-mode-for-developers/

16. GMS and AOSP – it makes a difference
Doze Mode is enabled only on GMS devices
This is where you can use an High-Priority Firebase Cloud Message to wake up the device and kick an application
temporarily out of Doze mode:
In Doze or App Standby mode, the system delivers the message and gives the app temporary access to network
services and partial wakelocks, then returns the device or app to the idle state.
Source: https://developer.android.com/training/monitoring-device-state/doze-standby.html

17. Whitelisting an application
• An app that is whitelisted can use the network and hold partial wake locks during Doze and App Standby.
However, other restrictions still apply to the whitelisted app, just as they do to other apps.
• An app can check whether it is currently on the exemption whitelist by calling
isIgnoringBatteryOptimizations().
• Users can manually configure the whitelist in Settings > Battery > Battery Optimization.
• Alternatively, the system provides ways for apps to ask users to whitelist them:
• An app can fire the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent to take the user directly to the Battery
Optimization, where they can add the app.
• An app holding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission can trigger a system dialog to let the user
add the app to the whitelist directly, without going to settings.
• The app fires a ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intent to trigger the dialog.
• The user can manually remove apps from the whitelist as needed.
Source: https://developer.android.com/training/monitoring-device-state/doze-standby.html

18. Testing for Doze Mode and App-Standby
You can simulate Doze mode using adb while your application is running:
$ adb shell dumpsys deviceidle force-idle
You can simulate App-Standby using adb while your application is running:
Force the app into App Standby mode by running the following commands:
$ adb shell dumpsys battery unplug
$ adb shell am set-inactive <packageName> true
Simulate waking your app using the following commands:
$ adb shell am set-inactive <packageName> false
$ adb shell am get-inactive <packageName>
Source: https://developer.android.com/training/monitoring-device-state/doze-standby.html

19. Two modes:
1. Full Storage Card Encryption Mode
• Matches what Adoptable Storage is with the same limitations
• Can be provisioned via StageNow
• Duplicates Android functionality so potential for future deprecation
2. Folder Encryption Mode
• Supports encryption in /data and on the Storage Card
• Allows a common encrypted implementation in common with non-Marshmallow devices in
your deployment
Android Marshmallow
Encryption & Adoptable storage – Interaction with Encrypt Manager

20. Android Marshmallow
Encryption & Adoptable storage
Reset Action Emulated
storage cards
Physical
storage cards
Adopted
storage cards
Enterprise
partition
Reboot Retained Retained Retained Retained
Full Device
Wipe
Wiped Wiped Wiped Wiped
Factory
Reset
Wiped Retained Wiped Wiped
Enterprise
Reset
Wiped Retained Wiped Retained

21. • Designed to reduce the value of stolen (consumer) devices
• Trusted factory resets:
• Do NOT mandate reentry any previously associated Google creds
• Invoked from device settings UI
• Untrusted factory resets:
• GMS Only
• DO mandate reentry of any previously associated Google creds
• Factory resets invoked from MX Power manager
• Factory reset packages available from Zebra support
• Note: If you forget your previously associated Google creds contact
Zebra support
Android Marshmallow
Trusted & untrusted factory resets

22. • Applications and services have to call scanner disable when device is suspending [e.g.
onPause/onDestroy callback].
• On Lollipop (Android v5.x) or KitKat (Android v4.4) devices we don't have imager
standby mode supported, in this mode imager would consume lowest power, with
TC51/TC56/TC70x/TC75x, using Marshmallow (Android 6.0), this was a requirement to
have lowest power on suspend.
• With this mode, imager loses all it's configurations which is done in enable, hence user
needs to recall enable again, however after disabling scanner, otherwise scan
framework will not accept another enable due to state machine.
Android Marshmallow
Imager goes into standby mode when devices goes into suspend.

23. • Android for Work started with 5.0 (lollipop). Announced at Google I/O 2014
• Initially targeted BYOD (Bring your own device) use cases
• Separation of ‘Work’ mode from personal applications
• ‘Work profile’ owned by a “Profile Owner” which would be a device policy controller (DPC)
• Enhancements for COPE (Corporate owned, personally enabled)
• Expectation that device or profile will owned by a DPC
• DPC is acting as device owner (DO) or profile owner (PO)
• Enhancements for COSU (Corporate owned, single use) [6.0+]
• Expectation that these devices will only have a device owner (DO)
• Typical Zebra device use cases
• Non-Zebra single use Android devices could be a payment terminal or airport check-in.
• DO provisioning via NFC prioritized by Google (also possible via adb)
Android Marshmallow
Android in the Enterprise: Recap

24. • COSU support (Corporate Owned – Single Use)
• Managed configurations via bundle data types
• Lock Task Mode in additional to lollipop’s consumer oriented ‘Pinning’
DEMOS
Android Marshmallow
Android in the Enterprise: COSU support in Marshmallow

25. Android Marshmallow
Managed Configurations

26. Android Marshmallow
Lock Task Mode

27. ANDROID NOUGAT

28. • Multi-Window Support
• Notification Enhancements
• Doze on the Go
• Data Saver
• Tile API
• Number Blocking
• New Emojis 
Android Nougat (7.0)
Behaviour changes affecting Enterprise
• WebView enhancements, now
using Chrome (on GMS)
• Enterprise updates (incremental)
• Hardware back keystore

29. • App Shortcuts
• Image Keyboard Support
• “Professional” Emoji   
• Storage Manager Intent
Android Nougat (7.1)
Behaviour changes affecting Enterprise

30. ANDROID ‘O’

31. • Background execution limits
• Background service limitations
• Implicit broadcast reception limitations
• Android background location limits
• Notification enhancements for ‘Channels’
giving users more granular control of
notification importance & how they should
be notified.
• Launcher shortcut pinning
Android O PREVIEW
Behaviour changes affecting Enterprise
• Enterprise updates:
• COMP (Corporate owned, managed profile)
devices
• Incremental improvements to DPC APIs
(new & existing).
• E.g. inter profile application communication.
• Autofill Framework
• Google Safe Browsing API in WebViews

32. Questions?

33. • Android M developer impact: https://developer.zebra.com/community/android/android-forums/android-
blogs/blog/2017/01/20/what-s-new-for-android-m-and-the-impact-on-zebra-developers
• Deploying applications on Zebra devices from JellyBean to Marshmallow & beyond:
https://developer.zebra.com/community/android/android-forums/android-blogs/blog/2017/02/08/deploying-an-application-to-zebra-
android-devices-ranging-from-jellybean-to-marshmallow-and-beyond
• Google official docs for:
• Lollipop: https://developer.android.com/about/versions/lollipop.html
• Marshmallow: https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html
• Nougat: https://developer.android.com/about/versions/nougat/android-7.0-changes.html
• O: https://developer.android.com/preview/behavior-changes.html
Useful Links
Android Alphabet Soup

34. Please take a moment to rate this session
using the APPFORUM mobile app.
THANK YOU

35. • Bullet text
Content Slide Title Goes Here
Sub title goes here

36. What are your options:
1. Continue to target API 22 (Lollipop)
2. Implement Google’s runtime model
3. Use an MX AppManager profile to install the application
4. Use an EMM that supports managed Android devices
Android Marshmallow
Dynamic runtime permissions