Android 绿色应用公约

Android Green App Initiative Android Green App Pact 4.0 (January 2020) Purpose This is an open pact launched to drive top Android ecosystem apps to jointly maintain a healthier device experience.

Device experience: Refers to the sum of overall device experience factors perceived by users that go beyond the explicit interaction process between users and apps. It includes device security, overall smoothness, power consumption level, heat generation level, etc.

Since the Android device experience is jointly shaped by the device's own hardware and software and the numerous apps installed on the device, the impact of the latter often expands rapidly as the number of installed apps grows. This spillover impact caused by apps presents a typical 'tragedy of the commons'. The damage a single installed app causes to device experience is often hard for users to directly identify, so device experience issues fail to get enough attention from app development teams for a long time. The consequences are indirectly borne by all apps, even the entire Android ecosystem.

Therefore, in addition to improving users' ability to identify device experience damage, it is necessary to drive the entire Android development community to optimize their apps' impact on device experience with higher standards, and jointly maintain a healthy Android ecosystem.

Open Compilation The content revision and expansion of this pact is open to the entire Android development community, following the principles of open acceptance, full discussion, and active revision. If you have any questions about the regulations (including implementation difficulties) or suggestions, please submit them via the GitHub issue tracker of this pact.

Core Principles Fully follow Android's own evolution direction (including new changes introduced in Android O), actively guide and assist app development teams to smoothly adapt to the latest Android changes. On the premise of ensuring core app functions are not affected, reduce unnecessary background app behaviors, and improve background behavior scheduling with more efficient, energy-saving scheduling mechanisms.

Only verifiable clauses are included in the mandatory regulations of the pact; clauses that require subjective judgment or have vague definitions (such as content related to interaction design) are not accepted.

All binding clauses provide recommended best practices or actionable adjustment methods.

When there is a potential conflict between functions and device experience, the principle that the final choice right is given to users is followed.

Regulations Mandatory Part Minimum Target SDK Version: 28 Reason: This is the key switch to leverage the optimization and security design of new Android versions. When an app's targetSdkVersion is lower than the current Android version of the device, the system will enable compatibility mode for the app, turning off some mechanism optimization and security design of new versions to ensure app running compatibility, which often comes at the cost of sacrificing device experience and security. To prevent app developers from deliberately abusing low target SDK versions to bypass Android mechanism optimization and security design, Google has officially launched the Target SDK Version retirement policy (minimum limit). Starting from August 2018, new apps published on Google Play are required to have a minimum target SDK version of 26 (starting from November 2018, all app updates are subject to this requirement), and the minimum requirement will be raised synchronously with the iteration of Android versions (the minimum requirement was raised to 28 in November 2019). Correspondingly, Android Q also pops up a warning when launching apps with target SDK version lower than 23.

Appendix: Official Android Target SDK Version Compliance Guide

Do not force request the 'Read phone status and identity (READ_PHONE_STATE)' permission when launching the app. Reason: IMEI (GSM) / MEID (CDMA) are non-modifiable or resettable unique identifiers in mobile phones and other devices with mobile communication functions, and are also key identifier information used to uniquely identify terminals in cellular network communication. IMEI/MEID not only allows ad networks to uniquely identify users throughout the device's lifecycle, but may also be used for device spoofing attacks in cellular networks, so IMEI/MEID leakage is a prominent issue in user privacy and mobile security. The description of this permission is also quite misleading, and sufficient risk disclosure has not been provided in the runtime permission system after Android 6.0. Since the Android system only displays it as 'Read phone status and identity', most users are confused when the app requests this permission, but still do not realize the security risks behind granting this permission.

Given that more and more countries and regions are implementing stricter privacy protection policies (such as the EU's GDPR regulation), especially restrictions on tracking non-modifiable or resettable device unique identifiers, Google explicitly prohibits using permanent unique identifiers such as IMEI/MEID for long-term user identification in its app market developer agreement. For details, please refer to the official documentation.

If some functions in the app (such as call-related features) depend on this permission, this permission can only be requested during the corresponding function interaction. Even if the user refuses to grant the permission, functions that do not depend on this permission must remain available.

For apps involving funds or property security (such as payment, e-commerce), if IMEI and other permanent unique identifiers are needed for security risk control, this permission can be requested when necessary (not at app launch), but a legally valid user privacy agreement must be provided to users, clearly including the scope of use and protection responsibilities for device permanent unique identifiers.

Except for user-initiated active interactions, avoid starting processes of other apps that are not running. Reason: Users usually have a certain tolerance for response time during active interactions (for example, from touch to interface change), while delays or lag during passive interactions (such as startup waiting, media playback) are more likely to cause user annoyance. If multiple processes are started during this period, in addition to the significant overhead of process creation itself and memory pressure, if the processes of other apps are started (the so-called 'cross-wakeup'), the other party's initialization overhead is a completely uncontrollable factor. Cross-wakeup often has a chain effect between apps, and is very easy to trigger 'chain wakeup' when there are many related apps installed (such as multiple apps integrating the same SDK), causing huge pressure on CPU, memory, IO and other resources in a short time, leading to a sharp decline in device smoothness, increased power consumption, and serious dual damage to user experience during app startup and overall device experience.

If you observe (or suspect) that the third-party closed-source SDK used has the above cross-wakeup behavior, it is recommended to integrate the lightweight open source auxiliary library Project Condom to identify and eliminate such cross-wakeup.

When using periodic tasks that request CPU wake-up (such as Alarm, JobScheduler, Sync Adapter), the period is recommended to be no less than 1 hour, with a minimum of no less than 30 minutes, and avoid continuing to schedule periodic events during unnecessary time periods (such as at night). Periodic tasks with an interval of less than 12 hours must provide an option to turn them off. Reason: Periodically waking up the CPU will interrupt the device's deep sleep state, causing a significant shortening of the device's standby time. According to Google's rough calculation in Project Volta, every 1 second of active work on the device will result in a loss of about 2 minutes of standby time. Most apps' background periodic tasks are mainly for network access, which usually lasts from a few seconds to dozens of seconds (even more than 1 minute). If such periodic background activities are scheduled too frequently, the impact on standby time is extremely significant. Since Android 4.4, Android has continuously optimized the background scheduling of periodic tasks in iterations, but all these efforts can only produce obvious effects in long-cycle tasks. If one app requests overly frequent periodic tasks, the entire system's standby time will be limited by the short bucket effect.

Starting from Android 9.0, the App Standby mechanism will restrict background periodic tasks for inactive apps.

On devices with Android 5.0 and above, avoid using the 'Read/Write external storage (READ/WRITE_EXTERNAL_STORAGE)' permission. (Exemption: Only file management apps) Reason: External storage is usually the storage location of users' private photos and videos, involving users' sensitive privacy. Except for file management tools, this permission should be avoided as much as possible.

Android devices now generally use virtual partitioning, and internal storage and external storage (External Storage) actually share the same physical storage location and quota, so there is no need to worry that internal storage is more likely to be exhausted than external storage. Android Q has introduced the new 'Scoped Storage' mechanism to restrict apps' access to shared storage areas between apps.

If it is really necessary to store app data (or cache) in external storage, or read and write data written by other apps in external storage, three situations need to be dealt with separately: 'User personal data (such as pictures, documents)', 'App private data' and 'Other app data'

User personal data: If it is only to facilitate users to export media files such as pictures, videos, and audio for other apps (such as WeChat) to read, it is recommended to use the API - Context.getExternalMediaDirs() newly added in Android 5.0. Files stored in this location can be read and written by the app itself without storage permission, while other apps (that have not targeted SDK version 29) can access it via MediaStore or directly (storage permission required), and users can also access it conveniently via file manager.

If compatibility with Android 4.4 and below versions is required, declare the external storage permission in the form of maximum SDK version, and directly read and write external storage on old version systems.

If you want users to freely decide the file storage location, you can use the 'Storage Access Framework' introduced in Android 4.4 to seamlessly connect to various local storage media (such as TF cards, USB OTG external storage, NAS) and third-party cloud storage services with simple APIs and universal interactions (similar to the standard dialog box used when opening/saving files under Windows), providing users with very flexible access and storage choices.

If compatibility with Android 4.3 and below versions is required, declare the external storage permission in the form of maximum SDK version, and directly read and write external storage on old version systems.

If long-term read and write of user-selected files or locations is required (such as automatic backup), you can use the API provided in Android 5.0 and above: ContentResolver.takePersistableUriPermission()

App private data: It is generally not recommended to write to external storage, because external storage can be accessed by other apps, which has data security risks, which means that user privacy-related data usually needs to be additionally encrypted and saved. If there are special reasons to write data to external storage, paths returned by related APIs such as Context.getExternalFilesDir(), Context.getExternalCacheDir() can be directly accessed by apps without any permission starting from Android 4.4.

If compatibility with Android 4.3 and below versions is required, declare the external storage permission in the form of maximum SDK version, and directly read and write external storage on old version systems.

Other app data: Regular apps cannot access private data saved by other apps in internal storage, but can access data files (or entire folders) saved by other apps in external storage under the user's explicit authorization. The specific operation method is similar to the above 'User personal data'. When requesting ACTION_OPEN_DOCUMENT, you can add DocumentsContract.EXTRA_INITIAL_URI to give the default path to guide users to select the corresponding location.

Recommended Part Publish on Google Play App Market Google Play App Market (hereinafter referred to as Google Play) is the world's largest app distribution channel in the Android ecosystem, and is the only pre-installed app market in most Android phones sold outside mainland China. Although Google Play does not occupy a dominant position in the domestic Android app distribution channel in China, this does not prevent app developers from attaching importance to publishing their apps on Google Play. Publishing apps on Google Play brings the following advantages:

Avoid the 'App ID' being maliciously registered, which becomes an 'accidental obstacle' on the road to internationalization in the future. (The importance is similar to domain name registration)

Gain competitive advantages on Google Play market as early as possible. Since accumulating reputation and reviews on Google Play is much stricter and more difficult than domestic app markets, investing a small amount of energy (adding a distribution channel) before competitors realize this can bring potential high returns, and avoid a passive situation after launching an internationalization strategy.

Align with Google Play market requirements and make full use of the tools and services it provides, so that the development team can connect with international mainstream technologies as early as possible, and reduce the threshold and resistance of future internationalization.