How Android P DP1 Restricts Non‑SDK Calls: Hidden API Mechanisms Explained

DP1 Restriction Overview

With the release of the Android P preview, Google added new limits on non‑SDK API usage: any application that references non‑SDK interfaces—whether directly, via reflection, or through JNI—will be restricted. The official preview documentation and the "App Compatibility Changes" section list three key points:

Framework documentation enumerates the SDK APIs that remain accessible.

Android P DP1 provides logs for non‑SDK interface calls.

Attempting to use non‑SDK APIs triggers specific exception types.

Log Format

When a non‑SDK method or field is accessed in the provided emulator, the protection mechanism outputs a log with the following structure:

Log header + Method/Field + API signatures (Greylist, Callers)

Log Header identifies the log source (Accessinghidden). Method/Field indicates whether the entry is a method or a field. API signatures correspond to the method/field descriptor.

Method signature example: class_descriptor>method_name(parameter_types)return_type Field signature example:

class_descriptor->field_name:field_type

Greylist Levels

Three restriction levels are defined, each backed by a text file:

Light greylist

Dark greylist

Blacklist

Implementation Principle

The greylist data originates from three text files that are merged into DEX format during the system source compilation. The ART virtual machine then converts the marked values from the DEX files into runtime access flags.

During app execution, the ART runtime reads the access_flags_ field of a method or field, determines its restriction level, and applies the appropriate policy.

Compilation Phase

During the build, three hidden‑api list files are generated:

hiddenapi-light-greylist.txt

hiddenapi-dark-greylist.txt

hiddenapi-blacklist.txt

These files are produced by scripts located at Framework/base/Android.mk and packaged into the build output under out/target/common/obj/PACKAGING/. The hiddenapi tool (found at out/host/linux-x86/bin/hiddenapi) processes the DEX files using the following arguments:

--light-greylist=out/target/common/obj/PACKAGING/hiddenapi-light-greylist.txt --dark-greylist=out/target/common/obj/PACKAGING/hiddenapi-dark-greylist.txt --blacklist=out/target/common/obj/PACKAGING/hiddenapi-blacklist.txt

Class Initialization Phase (ART Runtime)

At runtime, the ART ClassLinker resolves fields and methods via LoadField and LoadMethod. It reads the DEX access_flags_, decodes it using DecodeHiddenAccessFlags (which calls HiddenApiAccessFlags::DecodeFromDex), and re‑encodes the flags for the runtime representation.

The decoding maps the two‑bit greylist values to integers:

0b01 → HiddenApiAccessFlags::kLightGreylist 0b10 → HiddenApiAccessFlags::kDarkGreylist 0b11 → HiddenApiAccessFlags::kBlacklist These values are then written into the artmethod structure’s access_flags_ field (high bits) via EncodeForRuntime. During method invocation, the runtime checks the highest two bits of access_flags_ to enforce the policy.

Runtime Checks

Calls to methods or fields are validated through ShouldBlockAccessToMember (located in art/runtime/hidden_api.h). This function uses GetMemberAction and HiddenApiAccessFlags::DecodeFromRuntime to determine the action:

0 (0b00) – Allow

1 (0b01) – Allow with warning

2 (0b10) – Allow with warning and toast

3 (0b11) – Deny

The result is logged via the hidden‑API logging functions.

Summary

The article analyzes the core logic of Android P DP1’s non‑SDK restriction mechanism, covering the generation of hidden‑api list files, the compilation‑time processing of DEX access flags, and the runtime validation performed by the ART virtual machine.