Android Green Application Convention (Draft)

objective

It’s an open convention aimed at getting the best apps in the Android ecosystem to work together for a more benign “device experience.”

Device experience: the general term for the experience factors that belong to the whole device in the user’s perception, beyond the explicit interaction between the user and the application. Including equipment safety, overall fluency, power consumption, heating degree, etc.

Since the Android device experience is influenced both by the hardware and software of the device itself and by the number of applications installed on the device, the latter influence tends to expand rapidly as the number of applications installed increases. This spillover effect caused by application is a typical “tragedy of the Commons”. Among many installed applications, it is often difficult for users to directly identify the damage caused by an application to the device experience. As a result, the device experience problem has not been paid enough attention by the application development team for a long time. The consequences are indirectly shared by all apps, and even the Android ecosystem.

Therefore, in addition to enhancing users’ ability to identify the device experience damage, it is necessary to push the entire Android development community to optimize the device experience impact of their apps to a higher standard and jointly maintain a healthy Android ecosystem.

Open compilation

The content of this convention is revised and expanded for the entire Android development community, and the principles of open acceptance, full discussion and active revision are adopted. If you have any questions (including implementation difficulties) or suggestions about the convention, please submit them through the GitHub Issue tracker of this Convention.

Core principles

The core principles of this convention follow the evolution of Android itself (including the new changes introduced by Android O), actively guide and assist application development teams to smooth the pace of the latest changes in Android, and reduce unnecessary application background behavior while ensuring that the core functions of the application are not affected. A more efficient and energy – saving scheduling mechanism is used to improve the scheduling of background behavior.

When it comes to potential conflicts between features and the device experience, follow the principle of giving the user the ultimate option.

statute

A necessary part

  1. Target SDK Version >= 24 (Android 7.0)

    Reason: Project Svelte has some key enhancements in Android 7 that help reduce the impact of app background behavior on the device experience.

  2. Do not force the read phone state and identity (READ_PHONE_STATE) permission request at run time.

    Reason: The leakage of IMEI is a prominent problem in user privacy and mobile phone security. It is quite obscure, and it is still not clear enough to disclose information in the run-time permissions system after Android 6.0. Since the Android system only displays it as “read phone status and identity”, most users are confused when the application requests this permission, but are still unaware of the security risks behind granting this permission.

    If some functions (such as call related features) in an application depend on this permission (which must be logically reasonable), you can only request this permission in the corresponding function interaction. Even if the user refuses to grant permission, functions that do not rely on this permission must remain available.

  3. Avoid starting processes where the application is not running, except when triggered by an active user interaction. Reason: In active interaction, users usually have a certain tolerance for the response time of the interaction (such as the change from touch to interface), while in passive interaction (such as the wait in the startup process, media playback), the delay or lag are more likely to cause users’ aversion. If multiple processes are involved, in addition to the significant overhead and memory stress of the process creation itself, the initialization overhead of another application is a completely uncontrollable factor if the process is started (commonly known as “cross-wake”). Cross-wake up often has a chain effect among applications. When there are many related applications installed (for example, multiple applications integrated with the same SDK), it is easy to trigger “chain wake up”, which causes huge pressure on CPU, memory, IO and other resources in a short period of time, resulting in a sharp decline in device smoothness and an increase in power consumption. Both the user experience during application startup and the global device experience are severely damaged.

  4. The periodic Alarm and JobScheduler that wake up the CPU with requests must last at least 30 minutes. It is recommended that the interval be no less than 1 hour. Avoid continuing to schedule periodic events at unnecessary times, such as at night

    Cause: Waking up the CPU periodically interrupts the deep sleep of the device, shortening the standby time of the device. According to Google’s rough calculations in Project Volta, every second of active activity costs the device about two minutes of standby time. Periodic tasks in the background of most applications tend to be network accesses, usually lasting from seconds to tens of seconds (or even more than a minute). If such periodic background activities are scheduled too frequently, the impact on standby time is extremely significant. Android has been tweaking the background scheduling of periodic tasks in iterations since 4.4, but all of these efforts only yield noticeable results in long-cycle tasks. If one application requests too many periodic tasks, the entire system’s standby time will be limited by the short barrel effect.

  5. Provide users with the option to achieve the goal of “background-free”. (It does not have to be enabled by default)

    Cause: The continuously running service in the background is a hotbed of a series of device experience problems, such as increased power consumption caused by the continuous operation of the long connection baseband, device slowness caused by the restart of the service cycle when the memory is low, and intermittent CPU and I/O resource usage. Background purity is a major change in the principle of Android O’s application background constraints. It advocates the new principle of “do not open the background unless it is necessary”.

    Background-free: Meets the constraints of running in the Background in Android O application development requirements. The core requirement is that the application stops all background services within a short time after entering the background (up to 3 minutes and before the screen closes), and no new background services can be started during background activities triggered by other conditions (such as JobScheduler) other than receiving broadcast and executing the PendingIntent from the notification.

    For application scenarios with content updates, data synchronization, or weak real-time notifications, periodic polling is recommended to replace push in background purity mode. (See the minimum period constraint above)

  6. For Android 5.0 and above, the following broadcasts are not statically registered in androidmanifest.xml :(starting with Android O, static registration is no longer supported for all the following broadcasts)

    • Android.net.conn.CONNECTIVITY_CHANGE (Android 7 no longer support static registration, the alternatives to see the official development documentation)
    • Android. Hardware. Action. NEW_PICTURE (ditto)
    • Android. Hardware. Action. NEW_VIDEO (ditto)
    • Android.net.wifi.SCAN_RESULTS (rarely used, LocationManager is recommended instead)
    • Android. Intent. Action. USER_PRESENT (avoid)
    • Android. Intent. Action. ACTION_POWER_CONNECTED JobScheduler alternative (recommended)
    • Android. Intent. Action. ACTION_POWER_DISCONNECTED JobScheduler alternative (recommended)
    • Android. Intent. Action. MEDIA_… (Avoid using)

    To be compatible with older versions of Android, declare the required broadcast receivers in Androidmanifest.xml and use version-specific resource constants to ensure that the static broadcast receivers are disabled on Android 5.0 and above. As follows:

    AndroidManifext.xml

    <receiver ... android:enabled="@bool/until_api_21">
Copy the code

    /src/main/res/values/flags.xml

    <resources>
  <bool name="until_api_21">true</bool>
</resources>
Copy the code

    /src/main/res/values-v21/flags.xml

    <resources>
  <bool name="until_api_21">false</bool>
</resources>
Copy the code

Suggest some

  1. On Android 4.4 and above, avoid using read/write external storage permissions.

    Virtual partitions are now common on Android devices, where internal and external storage actually share the same physical storage location and quota, so you don’t have to worry about running out of storage space internally more easily than external storage. If it is necessary to write application data (or cache) to external storage, the application private data and user personal data (such as pictures and documents) should be handled separately.

    For users’ personal data, typical scenarios such as user-initiated “save picture” and “open document” interaction should be preferred to use the Storage Access Framework introduced in Android 4.4 and later. It can seamlessly connect various local storage media (such as TF card, USB OTG external storage, NAS) with third-party cloud storage services (such as Dropbox, Google Drive, etc.) using simple API, providing users with very flexible access choices. If an application needs to be compatible with An Android version later than 4.4, you are advised to set the permission for external storage in the form of the following versions and read and write external storage on an Android version earlier than 4.4.

    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="18" />

    You are not advised to write private application data to external storage because external storage can be accessed by other applications and may cause leakage. This means that there is often an additional need to encrypt and store data that is personal to the user. If there are special reasons need to write the data into the external storage, Context, getExternalFilesDir (), the Context, getExternalCacheDir () API related to the returned path starting from Android 4.4 is available for application to direct access, No permissions are required. If the application is compatible with Android 4.4 or later, use the methods specified in the earlier versions to declare read and write permissions on the external storage.

    Reason: External storage is usually the storage location of users’ private photos and videos, which involves users’ sensitive privacy. Avoid using this permission when possible, except for file management tools.

  2. Launch the Google Play app marketplace

    The Google Play App Market (hereinafter referred to as Google Play) is the largest app distribution channel in the Android ecosystem in the world, and the only pre-installed app market in the vast majority of Android phones released outside mainland China. Google Play is not the dominant Android app distribution channel in China due to well-known factors, but that doesn’t stop app developers from putting their apps on Google Play. Here are some advantages to putting your app on Google Play:

    • Google Play still has a considerable number of high-end audiences in China (roughly estimated at hundreds of thousands). Although their absolute base is not high, their comment weight and influence on Google Play are significant. Google Play’s relatively strict policing effectively endorses word of mouth among high-end users.
    • Gain an early competitive advantage in Google Play, as building word of mouth and reviews on Google Play is far more rigorous and difficult than in the domestic app market. Google Play has yet to officially enter the Chinese mainland market, but the possibility is rising fast. A small amount of effort (adding a distribution channel) can yield a potentially high return before other development teams realize it.
    • The requirements, tools and services provided by Google Play enable development teams to connect with international standards early and reduce the barriers and obstacles to future internationalization.