In this article we will look at the three most important changes in the new Android that cannot be ignored by any developer who set targetSdk = 23 and higher in his project.
Doze Mode - the “shutdown” mode, in which all devices on the Marshmallow go after some time of immobilization without charging.

App Standby - automatic deprivation of applications access to device resources, all of which the user has not opened for a long time.

Runtime Permissions is a new permission request model. Now, as developers, each time we turn to, for example, the device’s microphone, we must check whether our application has permission to access it.

At Google, the new Android release took a very important step towards optimizing battery performance. We all know how users like to stumble in the comments by saying: “Wacky Google Play Services” consumes 25% of my ******* S III’s battery, gopniks, give me back my precious iPhone, I’m not strong enough to endure bullying from Google. ” But these users have never set themselves a Battery Historian and are not aware that they eat battery free games from dubious authors and the same live wallpapers made on their knees, for example, but the user does not know this, and how to deal with a bunch of left-wing applications that mercilessly eat battery, he does not know.

Well now users will not have to take care of this. With the advent of the two new Doze Mode and App Standby modes, the operating system shuts off oxygen to all overcharging apps. How? Read on:

Doze mode

When the device on Android Marshmallow lies motionless and without charging, after an hour it goes into Doze Mode. Shutdown mode when almost all applications stop eating battery.

This does not happen immediately, but in steps:

ACTIVE - The device is in use or charging
INACTIVE - The device has recently left active mode (the user turned off the screen, pulled out charging, etc.)
... 30 minutes
IDLE_PENDING - The device is preparing to go into standby mode
... 30 minutes
IDLE - The device is idle
IDLE_MAINTENANCE - A short window is open so that the applications do their work.

We can bargain our applications by switching between these steps sequentially with:

$ adb shell dumpsys deviceidle step

At the moment when the device enters the IDLE state:

• Application access to the network is disabled until the application receives a high-priority GCM-push.
• The system ignores Wake locks. Applications can try to request a processor awakening as much as they like - they won’t receive them.
• Alarms scheduled in AlarmManager will not be called, except for those that will be updated using setAndAllowWhileIdle ().
• The system does not search for Wi-Fi networks.
• NetworkPolicyManagerService: skips whitelisted applications only.
• JobSchedulerService: all current tasks are canceled. New ones are postponed until awakening.
• SyncManager: all current ones are canceled, new ones are postponed until waking up.
• PowerManagerService: only application tasks from the white list are called.

Accordingly, if our application is chat, then we can send push from the server with the field priority = high .
And if we have an alarm application, then we must definitely call setAndAllowWhileIdle () or setExactAndAllowWhileIdle () for Alarm .

In many other cases, we don’t have to worry about this at all, after the user picks up the device, all the sleepy alarms and SyncAdapters will wake up and do their job. (Yes, I know that after exiting doze mode everything starts to sync and even Nexus slows down for 9 minutes two)

App standby

But not only when the device enters Doze Mode, our applications will be unable to drain the battery. The second mode called App Standby sends to the same isolation applications that do not fit the conditions:

• The user explicitly launched the application.
• The application has a process that is currently running in the foreground (Activity or foreground service, or another activity or foreground service is being used).
• The application created a notification that hangs in the notification list.
• The user forcibly added the application to the optimization exclusion list in the system settings

Exceptions

Perhaps now the developers of commercial voip nervously began to think about how to prohibit updating their users to Android Marshmallow, frightening in its rigidity. But do not worry, there is a special Whitelist in which the user can add exceptions with his hands. Applications from Whitelist are not afraid of either Doze Mode or App Standby.

To check whether our application got into Whitelist, we call the isIgnoringBatteryOptimizations () method .

The user can manually add / remove it from the list in the settings Settings> Battery> Battery Optimization.
But we can ask it ourselves using the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent or requesting the permissions REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, which will show a dialog for automatically adding to the whitelist with the permission of the user.

Read more:
developer.android.com/intl/en/training/monitoring-device-state/doze-standby.html#support_for_other_use_cases
newcircle.com/s/post/1739/2015/06/12/diving-into-android-m -doze

Runtime permissions

We got to the most famous change in Android Marshmallow. Moreover, this change requires us the greatest involvement in shoveling the application code. In short: the freebie is over.



Yes, every time our application requests, for example, a request for the user's location, we must check whether the application has permission from the user to do this. If there is, we turn to the system resources we need, if not, we request. Also, a user can permanently ban an application from accessing, then our only chance is to ask him to go into the settings and remove the ban by showing him an explanatory message why we need access.

It is worth noting that Permissions in Android are divided into two types:

1. Normal permissions , like network access and bluetooth.
2. Dangerous permissions . This list includes permissions for: calendar, camera, contacts, location, microphone, phone, sensors, SMS and external storage

That's just all the dangerous permissions that we must constantly check, because the user can disable them at any time. And at the first start, the application does not have access to them.

So, the sequence of our steps:

• Describe only PROTECTION_NORMAL queries in manifest
• The user will confirm them all during installation
• When an application needs access to one or more permissions from the dangerous group, check for permissions
• If there is no permission, request
• If there is no permission, explain what it will affect.
• If permission is obtained, continue to work.

To check the availability of permissions, we jerk ContextCompat.checkSelfPermission (Context context, String permission) .
To request permission by showing the system dialog, call ActivityCompat.requestPermissions () ;
The result of this request will come to the asynchronous callback in the onRequestPermissionsResult () activity , in it we will find out the user's decision for each of the requested permissions.

Request only those permissions that are really needed. There are still developers on Google Play who ask for everything in a row.

If possible, use an external Intent instead of a request.For example, for a photo or video, it often does not make sense to embed the camera in the application, it is much easier to use the external application

Request permission only before when you need it. Asking all permissions at the application startup is illogical (of the ones we need), their meaning is precisely in the fact that we request them in the context of their use. For example, the user understands why his banking client needs access to contacts - to choose one when sharing full name

Explain to the user why permission is requested. If the user nevertheless denied access to the application, and without it it cannot, it should explain as clearly as possible that without this permission it will not work further

More:developer.android.com/intl/en/training/permissions/requesting.html
Permission podcast: androidbackstage.blogspot.ru/2015/08/episode-33-permission-mission.html
Google sample: developer.android.com/ intl / ru / samples / RuntimePermissions / index.html
My github sample: github.com/nekdenis/Permissions_sample

Today we talked about the most notable changes in Android Marshmallow. Also, be sure to read the entire second article about other changes and innovations in Marshmallow . Thank you for your attention and speedy optimization of your applications for the new Android!