Android M Runtime Permission Mechanism and QQ Music Adaptation Experience

Android M (Marshmallow) introduced a dynamic runtime permission model that differs from the install‑time permission model used in earlier Android versions. This article explains the key concepts of the Android permission mechanism, shares QQ Music's practical adaptation experience, and discusses various permission‑related issues encountered on different OEM ROMs.

Android Permission Mechanism

Before Android 6.0, permissions were declared in the AndroidManifest and granted permanently at install time. Starting with Android 6.0 (API 23), permissions are classified into normal and dangerous groups, and dangerous permissions must be requested at runtime.

Adapting and Compatibility

To target Android 6.0+, set targetSdkVersion and compileSdkVersion to 23 or higher and add runtime permission checks. Compatibility behavior:

Old apps (targetSdkVersion < 23) continue to use install‑time permission granting on Android 6.0+ devices.

Apps that have been adapted to Android 6.0 still use install‑time granting on pre‑6.0 devices, but runtime permission code should only run on API 23+.

Normal vs Dangerous Permissions

Google evaluates the privacy impact of each permission and groups them accordingly. Normal permissions are granted automatically at install time, while dangerous permissions require user approval at runtime. Dangerous permissions are further grouped (e.g., READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE belong to the same group, so granting one grants the other).

Permission‑Related APIs

The main runtime permission workflow involves four steps:

Check if a permission is already granted. public int checkSelfPermission(String permission)

Request one or more permissions. public final void requestPermissions(String[] permissions, int requestCode)

Handle the callback. public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { /* handle result */ }

Provide additional rationale when the user denies a permission. public boolean shouldShowRequestPermissionRationale(String permission) { /* returns true/false based on prior user choice */ }

QQ Music Permission Adaptation Experience

Different Permissions, Different Timing

QQ Music distinguishes two permission request timings:

User‑triggered : Permissions needed for specific features (e.g., microphone for song recognition) are requested when the user accesses that feature.

App‑startup : Core permissions (device info, storage, network‑free data) are requested early, often at launch, after showing an in‑app explanatory dialog to avoid a sudden system prompt.

Startup Guard Shell

To prevent crashes before required permissions are granted, QQ Music isolates business logic behind a “shell” (e.g., a separate dex loader). The shell performs permission checks first; only after all necessary permissions are granted does it load the main dex and start normal execution.

Permission‑Related Fragmentation Issues (“Chaos”)

OEM custom ROMs often introduce proprietary permission systems that interfere with standard Android permissions:

Sensor Data Permission

Some ROMs display a “read motion data” permission dialog even though the standard Sensor API does not require any permission. The ROM blocks the callback if the user denies the proprietary permission.

Shortcut Creation Permission

While the com.android.launcher.permission.INSTALL_SHORTCUT permission is normal, certain ROMs require the user to manually enable shortcut creation in settings, causing silent failures.

Floating‑Window Permission

QQ Music uses WindowManager to add a floating lyric view. Some ROMs hide the standard SYSTEM_ALERT_WINDOW permission behind a custom switch in AppOpsManager . The following reflective code can check the hidden switch (op 24):

AppOpsManager manager = (AppOpsManager) context.getSystemService("appops");
try {
    Object object = invokeMethod(manager, "checkOp", op, Binder.getCallingUid(), getPackageName(context));
    return AppOpsManager.MODE_ALLOWED == (Integer) object;
} catch (Exception e) {
    MLog.e(TAG, "CheckPermission " + e.toString());
}

Because the location of the floating‑window setting varies across ROMs, the app must guide users to the appropriate system UI.