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

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

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

Google has taken a very important step towards optimizing battery performance in the new Android release. We all know how users like to comment on comments: “Wacky Google Play Services” eat 25% of my battery ******* S III, gopnik, give me back my precious iPhone, no strength, endure bullying from Google. " Only these users have never set themselves Battery Historian and do not know that they are consuming free games from dubious authors and the same live wallpaper made on the knee, for example, but the user does not know this, and how to deal with a bunch of left-wing applications that mercilessly eat up battery, he does not know.
')
Well, now users care about it and do not have to. With the arrival of two new Doze Mode and App Standby modes, the operating system blocks oxygen from all overly charged applications. How? We read further:

Doze mode

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

This does not happen immediately, but in steps:

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

We can deploy our applications by switching sequentially between these steps using:

$ 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 high-priority GCM-push.
• The system ignores wake lock'i. Applications can try to wake up the processor as much as they want — they will not receive them.
• The alarms scheduled in AlarmManager will not be called, except for those that are updated with setAndAllowWhileIdle ().
• The system does not search for Wi-Fi networks.
• NetworkPolicyManagerService: only skips applications from the white list.
• JobSchedulerService: all current tasks are canceled. New ones are postponed until awakening.
• SyncManager: all current ones are canceled, new ones are postponed until awakening.
• PowerManagerService: Only whitelist application tasks will be called.

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

In many other cases, we should not worry about it at all, after the user takes the device in his hands, all the alarms that have fallen asleep and the SyncAdapters will wake up and do their work. (Yes, yes, I know that after exiting doze mode, everything starts to shrink and even Nexus 9 minutes slows down two)

App Standby

But not only when the device gets into Doze Mode, our applications will not be able to discharge the battery. The second mode called App Standby sends the application to the same isolation, which does not fit the conditions:

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

Exceptions

Perhaps now the developers of commercial voip nervously began to think about how to prevent Android Marshmallow from being updated to its users, frightening by its toughness. 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 Doze Mode or App Standby.

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

The user can manually add / remove from the list in Settings> Battery> Battery Optimization
But we can ask for it ourselves using the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent or by requesting the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS perm, which will show the dialog for automatically adding to the listlist with the user's permission.

More details:
developer.android.com/intl/ru/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 to be the most involved in the shoveling of the application code. In short: the freebie is over.



Yes, yes, each time our application requests, for example, a request for a user's location, we need to check if 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, the user can permanently deny the application access, then our only chance is to ask him to go into the settings and remove the ban, showing him an explanatory message why we need access.

It should be noted 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 and we must constantly check, because the user can at any time to ban them. And at the first start of access, the application does not have them.

So, the sequence of our steps:

• Describe only PROTECTION_NORMAL requests in manifest
• The user will confirm them all when installing
• When an application needs access to one or more permissions from a dangerous group, check to see if there is permission.
• If no permission - request
• If permission is not - explain what it will affect
• If permission is obtained - continue working.

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

Request only those permissions that are really needed. There are still developers on Google Play who request everything

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

Request permission, just before you need it. To request all permissions at the start of the application is illogical (of those that we need), their meaning is that we request them in the context of their use. For example, the user can understand why his bank client has access to contacts — to choose one when sharing by name

Explain to the user why permission is being requested. If the user still denies the application access, and without it it cannot, it should be as clear as possible that without this permission it will not continue to work

Read more: developer.android.com/intl/ru/training/permissions/requesting.html
The podcast about permishenah: androidbackstage.blogspot.ru/2015/08/episode-33-permission-mission.html
Google sample: developer.android.com/intl/ru/samples/RuntimePermissions/index.html
My sample on github: github.com/nekdenis/Permissions_sample

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