![\"\"](\"https:\/\/jasonsblog.ddns.net\/wp-content\/uploads\/2026\/07\/image-45.png\")
<\/figure>\n\n\n\nWritten on July 4, 2026 by Nolen Johnson (npjohnson)<\/h6>\n\n\n\nDeveloper Verification: What it is, and how it affects you<\/h2>\n\n\n\nWhat is Developer Verification?<\/h3>\n\n\n\n
What is Developer Verification?<\/h3>\n\n\n\n
Android Developer Verification<\/a> is Google\u2019s requirement, rolling out regionally starting September 2026 (global by 2027), that apps be registered to an identity-verified developer before they can be installed on a \u201ccertified\u201d Android device, meaning any device shipping Google Play, Play Services, and the rest of the Google Mobile Services (GMS) suite. This applies regardless of the installation source; whether it is the Play Store, third-party stores, or direct APK sideload.<\/p>\n\n\n\n TL;DR: This will not affect LineageOS directly. But it may<\/em> affect users running the stock ROM on their device.<\/p>\n\n\n\n When the stock ROM<\/a> is installed on a certified device, package installation will be gated by the package \u201cAndroidDeveloperVerification\u201d, which will check against the developer\u2019s registered\/verified signing identity. Google is providing an \u201cadvanced flow\u201d<\/a> opt in for power users to install unverified-developer apps after acknowledging risk and waiting a full day. This is a one-time toggle to disable verification, not something you have to redo every time you wish to install a package.<\/p>\n\n\n\n We don\u2019t actually know. What we have is Google\u2019s stated reasoning, and even if you\u2019re skeptical of the outcome, it\u2019s worth taking at face value.<\/p>\n\n\n\n Google\u2019s public justification is fraud and malware prevention: they claim over 50x more malware<\/a> comes from sideloaded\/internet sources than from the Play Store, and that anonymous, disposable developer identities let bad actors get caught, rebrand, and redistribute the same malware in hours. They\u2019ve also pointed to regulatory pressure (the EU\u2019s DSA, India\u2019s IT Rules, etc.) pushing platforms toward developer traceability generally and framed the rollout order (fraud-heavy markets first: Brazil, Indonesia, Singapore, Thailand) as evidence the fraud rationale is the actual driver rather than a pretext.<\/p>\n\n\n\n That\u2019s the claim. Whether or not it\u2019s the whole story is a separate question.<\/p>\n\n\n\n Critics such as F-Droid, EFF, and \u201cKeep Android Open\u201d<\/a> point out that this also happens to route every install path through Google-controlled infrastructure, hands Google a kill switch over any app or developer worldwide, and arrives shortly after Google\u2019s antitrust lawsuits.<\/p>\n\n\n\n Both things can be true at once: real fraud is a problem and the restriction of developers is a convenient side effect of solving it this way – and we\u2019re not in a position to pretend we know Google\u2019s internal reasoning. We\u2019re just telling you what they\u2019ve said and what it changes; you can weigh the \u201cwhy\u201d yourself.<\/p>\n\n\n\n This changes nothing<\/em> for LineageOS, so we don\u2019t need to take any direct actions. This isn\u2019t a switch Google flips on our behalf, it is enforced by a dedicated application called \u201cAndroidDeveloperVerification\u201d ( This is a different situation from Play Integrity<\/a>: Play Integrity\u2019s attestation logic lives inside Play Services itself, and apps call into it directly for attestation. Developer Verification, by contrast, is its own standalone app that the frameworks are pointed at as a provider.<\/p>\n\n\n\n We have not ever, nor do we intend to ever, ship GMS. That means we\u2019re not subject to the Google Test Suite (GTS) certification Google apps are required to pass. Therefore we have no obligation to install \u201cAndroidDeveloperVerification\u201d or point the aforementioned configurations (overlays) at it.<\/p>\n\n\n\n If you sideload GApps packages<\/a>, be aware that a GApps package could choose to bundle \u201cAndroidDeveloperVerification\u201d and enable it. We\u2019re not aware of any reason an aftermarket GApps package would opt into that, since doing so would restrict what its own users can sideload. If your GApps provider ever does, you can simply switch to a different package.<\/p>\n\n\n\n They absolutely could. If that happens, we\u2019ll do what we already do for a number of annoying Play Services-provided over-the-air update implementations<\/a>: disable it globally.<\/p>\n\n\n\nHow does this affect LineageOS and its users?<\/h3>\n\n\n\n
Why is Google doing this?<\/h3>\n\n\n\n
What are we going to do about it?<\/h3>\n\n\n\n
com.google.android.verifier<\/code>), which the OS is then told is the<\/em> designated verification gatekeeper. For curious developers or other ROM maintainers, it is wired up through two framework overlays, config_developerVerificationServiceProviderPackageName<\/code> and config_developerVerificationPolicyDelegatePackageName<\/code>.<\/p>\n\n\n\nWhat can you do about it?<\/h3>\n\n\n\n
So it\u2019s a separate app\u2026 for now. Could Google move the functionality into Play Services?<\/h3>\n\n\n\n
What have we (LineageOS) done about all of this?<\/h3>\n\n\n\n