Android m new features doze and APP Standby mode detailed

Reference:
Optimizing for Doze and APP Standby
Android m new features doze and APP Standby mode detailed
Deep android6.0 Device Idle state
Does the third-party push service still work in Android M's Doze mode?

Optimizing for Doze and APP Standby

1. Starting with Android6.0, Android offers two power-saving functions to extend battery life : Doze and App Standby;

2. Presentation: When the device is not connected to a power source and the device enters Doze mode, the system will reduce battery consumption by delaying background CPU operation and network activity for applications that have not been used by the most recent user and allowing the application to be in the app standby state. Google said that testing on NEXUS5 and NEXUS6, when the screen is off, the average battery life increased by 30%;

3. Version requirements: Android6.0 (API level 23) and its later version;

4. Developer Impact: To ensure the user's best experience, it is necessary for developers to test the application in Doze and app Standby mode and adjust the code accordingly.

Second, understanding Doze1. Equipment into the Doze sleep mode timing:

• User does not operate the device for a period of time

• Screen off

• Device not connected to power charge

What is the application change in 2.Doze mode:

• The system tries to conserve battery by restricting application access to network and CPU-intensive services;

• Prevent applications from accessing the network, delaying application work, synchronization, and standard alerts;

• The system periodically provides a short time for the application to complete the deferred work activity and then enters Doze mode again. In this time slice, the system will provide maintenance Windows (Maintenance window) applications that can perform activities such as accessing the network, synchronizing, and alerting at this point.

The five states of the Doze mode are as follows:

1. Active: The mobile device is active

2. INACTIVE: Screen off into inactive state

3. Idle_pending: Every 30 minutes, let the app into the standby standby state

4. Idle: Free State

5. Idle_maintenance: Handling Pending tasks

As shown, the Doze period provides a short interval of time (30s) for applications to use the network and to process suspended activities.

From this diagram we can see that the system enters the doze mode, and the system will process the pending tasks over time, reducing the power consumption over time as the interval between the subsequent intervals becomes longer.

3. Exit Doze mode:

• Mobile devices
• Open screen
• Device Connection Power

The above three cases exit Doze mode, after which the apps revert to normal mode.

What are the limitations of 4.Doze?

• Network connections will be disabled

• Wake lock will be blocked

• Alarmmanager timed tasks are deferred until the next Maintenance window is processed, unless the method provided by Alarmmanager is used: Setandallowwhileidle () or Setexactandallowwhileidle ()

• The system will not scan hotspot WiFi

• Sync work will be banned

• Do not allow jobscheduler for task scheduling

5. What are the methods for adapting the doze mode?

• Doze affects Alarmmanager alarm clock and timer management activities, introducing two new methods in Android6.0: Setandallowwhileidle () and Setexactandallowwhileidle (), Calling two methods allows the system to respond to timed tasks in doze mode.

• Doze mode restricts the connection of the network, and if the application relies on real-time information, this will affect the app's experience. Then you need to use Google Cloud Messaging (GCM) Google clouds message (explained in detail later)

Third, understanding APP Standby

When the user does not touch the application for a period of time, the app is in the app standby state and the app is flagged as idle (idle). The application exits the app standby state unless any of the following conditions are triggered:

1. The user actively launches the app;

2. The app currently has a foreground process (or includes an active foreground service, or is used by another activity or foreground service);

3. The app generates a notification that a user can see on the lock screen or notification tray, and when the user device is plugged in, the system will release the app's standby state, allowing them to freely connect to the network and perform unfinished work and synchronization. If the device is idle for a long time, the system will allow idle apps to access the network once a day.

Iv. the difference between Doze and app standby:

Doze mode requires a screen to close (usually sleep at night or a long screen is closed before entering), while the app standby does not need a screen to close, the app will be in the background for a period of time is also limited by the connection network.

Wu, Deviceidlecontroller

Deviceidlecontroller is the main driver of the doze model. Next, I'll use device idle mode instead of Doze mode to describe "Doze" because it's more in line with the actual code.

5.1, deviceidle--new system services

If you have read the official documentation, you may have noticed the following commands that developers can use to learn about the current device's application behavior:

 
adb shell dumpsys battery unplug  
adb shell dumpsys deviceidle step

You may not be familiar with the commands above, Dumpsys is used to interact with system services (view their status). Deviceidle is what we have not seen before, it is a new system service. Used to detect whether to enter idle mode (doze mode)

$ adb shell service list | grep deviceidle 59 deviceidle: [android.os.IDeviceIdleController]

We can use '-h ' to see all of the Deviceidle's options:

 
$ adb shell dumpsys deviceidle -h  
Device idle controller (deviceidle) dump options:  
  [-h] [CMD]  
  -h: print this help text.  
Commands:  
  step  
    Immediately step to next state, without waiting for alarm.  
  disable  
    Completely disable device idle mode.  
  enable  
    Re-enable device idle mode after it had previously been disabled.  
  whitelist  
    Add (prefix with +) or remove (prefix with -) packages.

5.2, the Deviceidlecontroller five kinds of states

The Deviceidlecontroller maintains the five states that the device contains, and the five states of the doze described above are the same:

• The active– device is in use or is connected to a power supply.
• The inactive– device has been out of active state for some time (the user has turned off the screen or unplugged the power supply)
• idle_pending– Please note that we will enter the idle mode.
• The idle– device enters the idle mode.
• idle_maintenance– application window has been opened to do processing.

1, when the device is awakened and in use, the controller is in the active state,
2, inactive time timeout, the user off the screen and so on, will make the device status into the inactive.

3, inactive state, Deviceidlecontroller will be alarmmanager to set up his own alarm to drive the process:

A alarm will be set at a preset moment (this time in the M preview is 30 minutes).
When this alarm comes into effect, Deviceidlecontroller will go into idle_pending and set the same alarm again.

4, when the next alarm is triggered, the controller will enter the idle state, after entering this state, the application features will be completely limited.

5, idle state, will be idle and idle_maintenance two of the periodic jump between states. Idle_maintenance is the Maintenance window mentioned in Doze, in which the application can perform activities such as accessing the network, synchronizing, and alerting at this time.

The public API for these services (presented by the Ideviceidlecontroller interface) holds all the methods to access the whitelist. Applications (System applications or other third-party applications) cannot drive the controller state under any circumstances .

5.3, Deviceidlecontroller maintain a white list of applications

As you can see in the Help menu above, Deviceidlecontroller maintains a whitelist of applications, does not require additional parameters, and through the state of the dump service, we are able to see this list:

$ adb shell dumpsys deviceidle  
  Whitelist system apps: com.android.providers.downloads com.android.vending com.google.android.gms Whitelist app uids:  
    UID=10012: true  
    UID=10016: true  
    UID=10026: true  
  …

This list is divided into two parts: System applications and third-party applications.

System Application

The

System application is listed in the whitelist by the platform author through the configuration definition. Here is an example of a configuration definition from Nexus 6 that will use the GMS core (used in GCM), the store, and an arbitrary whitelist of apps for power monitoring:

 
 
<?xml version="1.0" encoding="utf-8"?>  
<!-- These are configurations that must exist on all GMS devices. -->  
<config>  
    <allow-in-power-save package="com.google.android.gms" />  

    <allow-in-power-save package="com.android.vending" />  

    <allow-in-power-save package="com.google.android.volta" />  
</config> 

Other system services can access these values through an instance of Systemconfig. Deviceidlecontroller uses Systemconfig.getallowinpowersave () to place these system-defined elements in the whitelist.

Note: When the device is in "power-down mode," the same configuration file determines which system application can open the service in the background.

Third-party applications

The remainder of the whitelist is user-defined, and these items can be added and deleted in two ways.

The first: Developers can use the whitelist command via the Dumpsys interface:

$ adb shell dumpsys deviceidle whitelist +com.example.myapplication  
$ adb shell dumpsys deviceidle  
  Whitelist system apps:  
    com.android.providers.downloads  
    com.android.vending  
    com.google.android.gms  
  Whitelist user apps:  
    com.example.myapplication  
  Whitelist app uids:  
    UID=10012: true 

The second type: Users can modify the whitelist by setting up (Settings-Battery, Ignore optimizations).

In addition: In the Xiaomi phone, the app is set to unlimited in the hidden mode or locked in the recent task, it will appear in the white list above.

Six, test doze and app Standby mode (ADB command) test doze mode

1, first ensure that your hardware or virtual device is Android6.0 or higher version of the system;

2, connect the device to the development machine and install your app;

3, run the app and let it run activities;

4. Turn off the screen of the device;

5. Run the following ADB command to bring the system into Doze mode:

$ adb shell dumpsys battery unplug$ adb shell dumpsys deviceidle step

You may need to execute the second command multiple times until the device is idle. Note that the first command means to unplug the power supply, even if it is plugged in with USB debugging, it will not charge. Recommended$ adb shell dumpsys battery resetto run, otherwise the phone will not charge the situation.

6. Observe if your app behaves in a place that needs to be improved.

Test app Standby mode

Step 1-3 with Test doze mode

4. Run the following ADB command to force the system into app Standby mode:

shellshellsettrue

5. Simulate waking your application using the following command:

shellsetfalseshellget-inactive <packageName>

6, observe your app, make sure the app can be restored from standby mode gracefully, should check the app notification and backstage can continue to work as expected.

Seven, the client use method:

1. The app can send the action to action_ignore_battery_optimization_settings Intent guide the user into the Settings screen to set the application into the whitelist list.

2. The application can also use the Arequest_ignore_battery_optimizations permission to trigger a system dialog to allow the user to add to the whitelist without having to go to the Setup interface to set it up.

Of course, the official also provides the option for users to remove your app from the Battery optimizer whitelist. This whitelist will also be used by another new feature of Android M App standby, so the user can simply control it, which means the device does not fully trust the whitelist.

This whitelist is just a suggestion from Google, which means you can use the above two methods to guide the user to whitelist your app in the following cases

The official cited the white list example:

Summarize:

I think the doze mode and the app Standby mode restrict the app's permissions to the same type. Are entering the idle state. Only the conditions required for entry and exit of the respective mode are different, and the cycle of controlling the app after entering the mode is different.

The launch of the Doze model itself is designed to reduce battery consumption, and Google wants to unify the use of GCM to communicate messages, and for domestic development, it does bring a lot of trouble:

1. Some of the domestic development of the message push mechanism (push) will be affected;

2. If using GCM, in the domestic use of GCM delay high, for instant messaging products to choose also need courage ah;

3. Domestic third-party handset manufacturers such as Huawei, Xiaomi, Samsung, custom ROM will also use a custom push message mechanism. How does this allow the same app to choose which push mechanism is compatible?

Workaround:

1. User add app to battery optimizer whitelist list;

2. Developers use the Action_ignore_battery_optimization_settings intent and Arequest_ignore_battery_optimizations permission settings provided by Google to ignore (recommended);

3. Use GCM provided by Google;

4. Bypass doze mode with so.

I use MIUI 7.5 (Android 6.0.1) test process found that I maintain a long connection into the standby mode, the network is broken (mobile phone other app network normal), but running in the background of the code is still running, log can output to the phone's files, is not even the Internet. According to the official description into the standby mode, the work should be suspended, but why the background code is still functioning?? Please give me a little guidance.

• The main process can be manually set to Standby mode,
• The child process of the app cannot be set to standby mode, but if the main process is standby mode, the child process will also be standby mode. False if you use a command to view the standby state of a child process.
• In the case of normal use of the phone, the main process can not enter the standby mode, the feeling is to use so bypass Standby mode. Specific so file is how to achieve, also ask the big God pointing.

Android m new features doze and APP Standby mode detailed