Understanding Android P Hidden API Restrictions and Their Implementation

With the release of the Android P preview, Google introduced a new restriction that blocks applications from invoking non‑SDK interfaces, regardless of whether they are accessed directly, via reflection, or through JNI.

The system logs such attempts using a specific format that includes a log header, the method or field signature, API signatures, a greylist level (light, dark, or blacklist), and the caller type (reflection or JNI).

During the compilation phase, three text files— hiddenapi-light-greylist.txt , hiddenapi-dark-greylist.txt , and hiddenapi-blacklist.txt —are generated from the framework source. The hiddenapi tool processes these files, parses the dex files, and rewrites the access_flags_ of the listed methods and fields to embed the restriction level.

The rewriting algorithm examines the low and high bits of the original access_flags_ . If the low bit is set, it XORs the visibility flags; if the high bit is set, it ORs the hidden‑API bits, resulting in a modified flag that indicates the hidden status.

At runtime, the ART virtual machine’s class linker loads fields and methods. Functions such as DecodeHiddenAccessFlags read the modified flags from the dex cache, and EncodeForRuntime stores the two‑bit restriction value into the highest bits of the ART method/field structures.

When an app calls a restricted API, ART invokes ShouldBlockAccessToMember (found in art/runtime/hidden_api.h ) via GetMemberAction . This function checks the encoded flags and, if the call is prohibited, logs the violation and blocks the access.

The article concludes that the hidden‑API mechanism in Android P DP1 combines compile‑time dex modification with runtime flag checks to enforce non‑SDK API restrictions, and notes that further details will be added as the stable release evolves.