Decompiling the Android Developer Verifier app - BLCK<br>F-Droid blog has published an article<br>titled What We Talk About When We Talk About Malware. The article<br>is rather critical and claims that a pre-loaded Android app called Android Developer Verifier behaves like a trojan<br>horse. The article contains little evidence for its claims. But I would like to give it credit for making me aware of the<br>app. This post is my analysis of the Android developer verification timeline, policy, and of the decompiled source code.<br>The Android Developer Verifier app&rsquo;s version 1.0 was released<br>in July 2012. Since October 2025, it has started<br>receiving more updates. This coincides with the post to an Android Developers Blog<br>titled A new layer of security for certified Android devices.<br>The blog states:<br>&ldquo;Starting next year, Android will require all apps to be registered by verified developers in order to be installed by<br>users on certified Android devices.&rdquo;<br>The timeline of the rollout is reportedly:<br>AnnouncementAug 2025Google announces developer verificationEarly accessOct 2025Developer verification early access begins. Invitations will be sent out gradually.Verification opensMar 2026Verification opens for all developers.Enforcement beginsSep 2026Requirements go into effect in Brazil, Indonesia, Singapore, and Thailand. At this point, any app installed on a certified Android device in these regions must be registered by a verified developer.Global rollout2027 and beyondRequirements roll out globally.Android 16, released in June 2025, introduces developer verification requirements.<br>The release compatibility documentation<br>contains useful info. I encourage you to read the original text. This is my summary of the relevant points:<br>Android 16 devices that configure a developer verifier in config.xml must invoke DeveloperVerifierService for<br>every package installation and update.<br>The verifier service must prevent the installation of a package if the developer identity verification fails. Failure<br>means the app is unverified.<br>The verifier policy doesn&rsquo;t apply to installation via ADB. Or if developer verification policy is set to FAIL_WARN<br>or<br>FAIL_OPEN , verification is incomplete, and user clicks install anyway.<br>DeveloperVerifierService was introduced in Android 16, coinciding with the update of the Android Developer<br>Verifier app.<br>Code analysis<br>APK: com.android.google.verifier version 1.0.866414232 from March 30

I decompiled the APK using Dex to Java decompiler that produces Java source code where<br>most<br>of the business logic is obfuscated. For a better look into the business<br>logic, Apktool decompiles the apk to smali code (type of assembly language)<br>which is not as easily readable.<br>java -jar apktool_3.0.2.jar d com.google.android.verifier.apk<br>I tasked DeepSeek with analysing the decompiled code. Then, I verified the code execution path manually. I also<br>referenced my findings to this comprehensive analysis someone already did.<br>Findings<br>The com.google.android.verifier app is invoked before a package installation. It&rsquo;s a pre-installed,<br>system-privileged app that acts as the platform&rsquo;s developer verification service. It hosts the DeveloperVerifierService .<br>Once invoked, the verifier reads the policy. [1]<br>Then, it extracts SHA-256 hashes of APK signing certificates. [2]<br>It also collects installer identity, device serial number, device owner info and other basic information. It reports the<br>result back to the PackageInstaller . [3]<br>The verification is local. The app pulls flags that originate from Google&rsquo;s server. [4] It<br>validates the signing<br>certificate fingerprints and reports them to PackageInstaller , a separate service, and it decides what to do based<br>on<br>the policy value:<br>DEVELOPER_VERIFICATION_POLICY_NONE = 0: Do not block install.<br>DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN = 1: Block install when verification fails. If<br>verifier can&rsquo;t be reached, let it through.<br>DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN = 2: Warn user if verification fails, let them install<br>anyway.<br>DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_CLOSED = 3: Block install when verification fails.<br>The app has two verification paths. The original enforcement approach works by sending the verificator result via gRPC<br>to the Play Store, which applies its<br>own policy. The new enforcement works by pulling policy flags and trusted fingerprints from Google&rsquo;s servers to a local cached store. The<br>enforcement is delegated to PackageInstallerSession .<br>Conclusion<br>The app verifier is a system app and can&rsquo;t be uninstalled. The PackageInstaller is invoked during install and if app<br>verifier is not present, it may or may not block the install. In any case, existing apps are not removed. However,<br>updates to<br>installed apps are checked. The new verification path is enabled by a flag pulled from Google server.<br>No network calls are made in the verification logic. App verifier compares the app&rsquo;s signing certificate and fingerprint to...