Android trust: modules, root stores and process views

A proxy CA works in the browser, yet an Android application still fails its TLS handshake. Before attributing that difference to pinning, establish where the application process obtains its trust anchors. The platform build, Conscrypt module, certificate-source implementation and mount namespace all matter.

Pixel 3a observations recorded before June 2025 illustrate three separate conditions: a module contains certificates, a process can see them, and an application accepts them. Fixed source revisions help explain those observations; they do not turn a device record into a compatibility guarantee for every phone with the same Android version.

Record both update tracks

Mainline lets selected components update independently of a full OTA. An entry such as "Android 13" omits the Google Play system update (GPSU) and active Conscrypt version. Even the settings page can show three different points in time:

Keep these settings-page observations separate from the Pixel 3a comparisons below; they are not a combined baseline from one device. Collect the following read-only device information as well, subject to the build's access controls:

adb shell getprop ro.build.fingerprint
adb shell getprop ro.build.version.sdk
adb shell ls -ld /apex/com.android.conscrypt*
adb shell cat /apex/apex-info-list.xml

Check isActive, rather than assuming that the newest filename identifies the module in use. One recorded active entry contains these fields:

<apex-info
    moduleName="com.android.conscrypt"
    modulePath="/data/apex/decompressed/com.android.conscrypt@331411000.decompressed.apex"
    preinstalledModulePath="/system/apex/com.google.android.conscrypt.apex"
    versionCode="331411000"
    isFactory="true"
    isActive="true" />

The isFactory="true" flag matters. A file under /data/apex/decompressed is not, by itself, evidence of a subsequently installed update: a compressed factory APEX also gets extracted there. Interpret the path together with the active flag, preinstalled location and version. The APEX boot and decompression documentation explains this layout.

Identify the directory-selection class

The conventional location is usually /system/etc/security/cacerts; the module location is /apex/com.android.conscrypt/cacerts. Existence alone does not determine which one is read. Two similar selectors also live at different layers:

These are different classes in different source trees, not simply two successive versions of one module function. The framework class ships with the platform. Installing a new Conscrypt APEX does not imply that its framework counterpart has also been replaced.

For a directory that can be listed normally, this illustrative expression captures the Conscrypt condition. The actual source obtains the runtime SDK through getSdkVersion():

boolean useApex(Integer sdk, String property, boolean exists, int entries) {
    return sdk != null
        && sdk >= 34
        && !"true".equals(property)
        && exists
        && entries > 0;
}

Java's System.getProperty("system.certs.enabled") is separate from Android's property service. Setting a same-named value with setprop or resetprop does not establish that this Java property changed. The comparison is also exact: "True" and "true" are different inputs.

Identify the class that actually executes on the device and its build before applying either rule. Compare the pinned Conscrypt source with the Android 14 framework source.

Presence is not activation

The Pixel 3a records distinguish module contents from runtime selection:

A newer layout can therefore appear on an older platform without establishing that Android 11 or 12 generally uses module roots. A separate Android 13 observation depended on the APEX directory, but the earlier module version was not retained and the behavior was not reproduced on an identical build. It does not support a broader version rule.

The relevant package metadata for version 351412000 identifies com.google.android.conscrypt, not the APEX module name com.android.conscrypt:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.google.android.conscrypt"
    android:versionCode="351412000">
    <uses-sdk android:minSdkVersion="30" android:targetSdkVersion="35" />
    <application android:hasCode="false" />
</manifest>

The package's minSdkVersion="30" does not cancel an SDK 34 gate inside a root-directory selector. Likewise, hasCode="false" does not mean the entire APEX contains no JAR or native library. These are package metadata fields, not an inventory of the APEX payload.

Moving or rolling back modules also depends on signatures, architecture and platform acceptance rules. After a staged installation, reboot and check the active version again. One INSTALL_FAILED_DUPLICATE_PACKAGE error from treating the file as an .apk does not characterize every non-staged installation path.

Inspect the target process's mounts

Only after establishing that the implementation selects the APEX path should the investigation move to file visibility. This diagram is a diagnostic sequence, not a complete TLS call stack:

flowchart TD
  accTitle: From the active implementation to application trust
  accDescr: Identify the certificate source, inspect files in the target namespace, then check disabled entries and application policy.
  A["Certificate-source class actually used"] --> B["Selected system or APEX path"]
  B --> C["Target process mount namespace"]
  C --> D["Visible files and submounts"]
  D --> E["User certificates, disabled entries and caches"]
  E --> F["Application trust configuration and extra checks"]

A root-management module may merge certificate sets, overlay the conventional directory and then bind it onto the APEX path. That still leaves process visibility to verify. Record mount propagation, zygote state and application creation time separately; the current shell does not represent every application's view.

These read-only templates run in a device-side shell. Replace PID with the verified target process ID, and check permissions and the available nsenter implementation first:

readlink /proc/PID/ns/mnt
cat /proc/PID/mountinfo
nsenter --mount=/proc/PID/ns/mnt -- \
  ls -l /apex/com.android.conscrypt/cacerts

After changing zygote's view, inspect both newly created applications and processes that already existed. After restarting an application, record whether it came from the expected zygote. A path visible in the shell is not evidence that the application is using those certificates.

A plain bind can omit submounts

In one Android 15 record, individual system certificate files were separate mounts. Their paths included bf64f35b.0, 5acf816d.0 and d41b5e2a.0 under /system/etc/security/cacerts. The filenames identify entries in that mount record; they are not used here to infer certificate subjects.

An empty interface establishes a display result, not a device-wide certificate count of zero. A plain --bind does not recursively copy the source's submounts. --rbind handles the mount subtree, with unbindable subtrees pruned. The Linux shared-subtree documentation defines that distinction.

The corresponding operation has this form on a test device whose source tree and propagation relationships have been checked. Tool paths and supported options depend on the installed implementation:

nsenter --mount=/proc/PID/ns/mnt -- \
  mount --rbind /system/etc/security/cacerts \
  /apex/com.android.conscrypt/cacerts

This addresses a particular mount-tree problem, not every interception failure. Save the target namespace's mount baseline, compare submounts and actual files afterward, and restore the recorded hierarchy when reverting instead of stacking more binds. SELinux labels, certificate encoding and an application's independent trust store remain separate checks.

Disabled entries and certificate caches

A system CA can remain in a read-only directory while the user disables it. In the pinned Conscrypt implementation, deleteCertificateEntry() handles a system entry by writing its certificate into the deleted-entry directory. getTrustAnchor() checks candidate system anchors against that state. User-added entries take a different deletion branch.

The framework's SystemCertificateSource checks a same-named marker in the current Android user's cacerts-removed directory. UserCertificateSource reads that user's cacerts-added directory. Common locations for user 0 are shown below; resolve other users from their actual user IDs:

/data/misc/user/0/cacerts-added
/data/misc/user/0/cacerts-removed

Do not apply those paths to every standalone Conscrypt instance. The pinned commit defaults to $ANDROID_DATA/misc/keychain and exposes setDefaultUserDirectory(). The caller's configuration determines the final location.

There is also cached state. Android 14's DirectoryCertificateSource caches enumeration results. Its handleTrustStorageUpdate() clears that set without reselecting the directory supplied to the constructor. Distinguish invalidating the certificate set from reconstructing the source object when testing a path or property change.

Close the verification loop

An offline check used javac 13-ea. It extracted shouldUseApex() from the fixed commit and replaced only the SDK-query entry point. The framework function retained its logic with its paths redirected to local fixtures. Cases covered five SDK inputs, four property values and three directory states; the readable nonempty directory held a marker file, not a simulated valid certificate.

PASS Conscrypt source method: 60 cases
PASS framework source method with redirected fixture paths: 12 cases

These results validate selector branches. They are not new Pixel runs, mount experiments or TLS handshakes. Device validation still needs to reach the application:

Whether a modern application trusts user CAs depends on its target API and Network Security Configuration. A custom TrustManager, native networking stack or pinning can add further conditions. When the application is yours to modify, explicitly configuring debug-build trust anchors is more controlled than depending on device-wide mount changes. File visibility is a necessary diagnostic check, not the final trust decision.

References

• AOSP: Mainline architecture
• AOSP: Conscrypt and root-store updates
• AOSP: APEX format, installation and activation
• Google Conscrypt: pinned TrustedCertificateStore
• AOSP Android 14: SystemCertificateSource
• AOSP Android 14: UserCertificateSource
• AOSP Android 14: DirectoryCertificateSource
• Linux: Shared subtrees
• Android Developers: Network Security Configuration