On August 25, 2025 Google published a blog that starting in 2026, Android will require all apps to be registered by verified developers in order to be installed by users on certified Android devices. This applies to all apps installed from outside the Google PlayStore from either third part app stores like F-Droid, or directly from sites via browsers/file manager apps. Publishing apps on Google PlayStore already has had these same requirements since July 12, 2023. The verification requirements for all apps will engage for Brazil, Indonesia, Singapore and Thailand in September 2026 and engage globally in 2027 and beyond.

There has been lot of noise and backlash regarding the new requirements since then. Malware being deployed both outside and from PlayStore is a big issue and is obviously a cause for concern and a legitimate reason for how developer verification can help reduce it, but not finish it.

I have been thinking over this the past few months and have had a lot of random thoughts regarding this. I finally decided to write a post on this to provide a detailed overview for why and how will these changes will be implemented and the huge amounts issues they will cause. I didn’t have time for all this, but there hasn’t been positive progress regarding this so I was forced to take time out at expense of other work. I have also been researching into how developer verification will work internally at the Android framework level and have posted the details in the Internal Implementation section.

I am not against the developer verification requirements as malware is obviously out of control, but I am very against Google not providing a non-adb opt-out for users to be able to install apps from unverified developers including open source apps on the devices they own. A huge amount of issues related to package names and signing keys and even legal issues also exist, and that makes the current design not being viable for everyone. In addition to this post I have opened the Android Developer Verification Proposed Changes issue on Google’s issuestracker at https://issuetracker.google.com/459832198 with a proposal on how a possible opt out can be implemented.

Contents

• Overview and Issues
• Internal Implementation

---

Overview and Issues

I wrote most of this section before the Epic Games Inc vs Google LLC case settlement was announced, so it is mostly from the earlier perspective, but I have made changes in regards to it too. Additionally, the case settlement requires Google to implement Registered App Stores in future Android versions, but I don’t know how it will affect developer verification requirements, but they probably will stay in some form, hence an opt out will still be necessary.

The following subsections quote various texts from the following Google’s developer guides and support questions below, and also from people in the Android developer verification youtube video.

• https://developer.android.com/developer-verification/guides/faq
• https://support.google.com/android-developer-console/answer/16561738
• https://developer.android.com/developer-verification/assets/pdfs/introducing-the-android-developer-console.pdf
• https://android-developers.googleblog.com/2025/08/elevating-android-security.html

Contents

• How can apps be installed on Android devices?
• Epic Games Inc vs Google LLC case settlement affect stores and developer verification?
• How will limited distribution work for hobbyist/students?
• How will ADB work?
• Are sideloading and other stores going away?
• Why is there a $25 fee?
• How will registering existing and new package names work?
• How will signing challenge work?
• How will verification work at install time?
• How will enterprise devices work?
• How will verification affect F-Droid and other stores?
• How will verification affect apps on F-Droid and other stores?
• How will this affect Termux app?
• How will this affect Open Source apps?
• How will this affect APK Native Library?
• What if your national identity card gets stolen?
• Will Google block apps of developers distributing apps even outside PlayStore
• Will Google give identity info of developers distributing apps even outside PlayStore?
• Will Google block apps of developers from specific countries?
• Will Google block apps of developers that are engaged in court disputes with Google and other US companies, or competitors of US companies?
• Will Google block or not verify apps that violate its content policy?
• Will this be used for policing Android developers worldwide?
• What about anonymity?
• Google contacting other stores

How can apps be installed on Android devices?

The app APK files can be installed in the following ways.

• Install Without Root/ADB

• Install with INSTALL_PACKAGES

• Install with REQUEST_INSTALL_PACKAGES

• Install Wit Root

• Install Wit ADB

Install Without Root/ADB

The are current 2 ways users can install apps without root/adb with normal install mechanism.

Install with INSTALL_PACKAGES

System apps granted the INSTALL_PACKAGES permission with system|signature protection level, that allows them to automatically install applications in background, like the Google PlayStore.

This permission is normally automatically granted to the system apps.

Install with REQUEST_INSTALL_PACKAGES

System or third party apps granted the REQUEST_INSTALL_PACKAGES permission with appop|signature protection level, that allows them to request the installation of the package, which starts Android’s own Package Installer app user prompt with Install/Cancel buttons. This is what is normally used by browsers, file managers and third party app stores, like Chrome and F-Droid.

This permission needs to be granted by the users with the Install unknown apps prompt shown during installing if calling app does not have the permission to install apps, or by manually granting it from Android Settings -> Apps (-> Advanced) -> Special app access -> Install unknown app.

On Android >= 12 apps requesting UPDATE_PACKAGES_WITHOUT_USER_ACTION permission can also update their own app or any other app that it previously installed itself in background without a user prompt if certain other conditions are met detailed in PackageInstaller.SessionParams#setRequireUserAction(int).

The REQUEST_INSTALL_PACKAGES permission cannot be granted to apps during phone calls as part of Enhanced Confirmation Mode since Android 15 to prevent scammers from manipulating users into downloading and installing apps from the internet during a call. (1, 2) The Play Protect app scanning toggle is also disabled during phone calls. (1)

Install With Root

Apps can be installed on rooted Android devices with su by running the /system/bin/pm install command provided by the Android system as the shell user which belongs to the shell/adb package (com.android.shell) (output="$(su shell -c pm install <args...> 2>&1 </dev/null)"; echo "$output").

Install With ADB

Apps can be installed with adb by running the adb install command either from a PC or directly from device, which internally is same as the /system/bin/pm install command provided by the Android system.

The adb command can either be run over a USB connection from a PC after enabling USB debugging in Developer Options, or after setting up Wireless debugging in Developer options.

To setup the Wireless debugging on Android < 11 requires enabling it with USB debugging from a PC on every reboot of the device by running the adb tcpip 5555 command (1), but on Android >= 11, it can be setup directly from the device itself without a PC as a localhost/127.0.0.1 connection (1). Apps like Termux (android-tools package) or Shizuku app can then be used to connect to the Wireless debugging to run commands as adb.

Epic Games Inc vs Google LLC case settlement affect stores and developer verification?

• https://www.reuters.com/sustainability/boards-policy-regulation/google-proposes-app-store-reforms-settlement-with-fortnite-maker-epic-games-2025-11-05/
• https://fingfx.thomsonreuters.com/gfx/legaldocs/xmpjqoyrbvr/Epic%20-%20Google%20settlement%2020251104.pdf Proposed Modified Injunction

1. The Proposed Modified Injunction Would Enhance Competition in App Distribution.

The Proposed Modified Injunction addresses the Court’s conclusions regarding the continuing effects of Google’s past conduct through a new Registered App Store remedy, which replaces the Catalog Access and Third-Party Store Distribution remedies in the Existing Injunction.

The Registered App Store remedy simplifies the process for an Android app store to be installed on user devices and for users to download apps from such stores, while allowing Google to take reasonable steps to protect user security and safety. Those steps are not left open-ended but are instead specified in the parties’ Settlement. The Registered App Store Remedy is also timed to last for roughly six-and-a-half years—over twice as long as the corresponding remedies in the Existing Injunction—which will provide competing app stores even greater certainty and predictability.

The Registered App Stores remedy requires Google to modify the Android operating system to simplify the installation and download flow for all Registered App Stores. When a user downloads a Registered App Store, the user will see a single screen explaining that (1) the store is a registered app store, (2) upon installation the store will be able to install and manage apps on the device, and (3) the entity responsible for the app store will manage downloads and updates for apps distributed by the store. The parties have agreed on neutral language to explain these details to the user. If the user clicks “install,” the store will be installed and the operating system will give it the permissions necessary to install and update apps. With those permissions, the installation flow for apps downloaded and installed through Registered App Stores will be similar to the flow for downloading apps from the Play Store.

To address Google’s view that app and app store downloads could be used by bad actors as a vector for fraud or malware, the parties have also agreed that Google may apply specified neutral safety and security criteria to review stores for certification as Registered App Stores. That process is conceptually similar to a remedy proposed by Epic’s expert at trial. (See Trial Tr. vol. 11, 2156:25-2163:2, Nov. 21, 2023, Dkt. No. 844 (“Android is going to check to see if the app bears that notarization sort of stamp of approval. If so, Android does not show that friction screen . . . .”).) Google will be permitted to charge reasonable fees to cover the operational costs of this review process. And the Technical Committee can provide guidance on any implementation questions relating to this remedy.

The Registered App Stores remedy will promote competition in the Android app distribution market by streamlining the process for downloading qualified Android app stores and downloading apps from those qualified stores, thereby making it easier for Google Play store competitors to offer their product directly to Android users, while also ensuring the safety and security of Android users.

The Existing Injunction took a different approach to this issue, requiring Google to offer, for three years, its catalog of apps to competitor app stores (Catalog Access) and to distribute, for three years, competitor app stores through the Play Store (Third-Party Store Distribution). The Court recognized that “there are potential security and technical risks involved in making third- party apps available, including rival app stores,” and the Court established the Technical Committee to help address them, recognizing that the Court would still need to be the decision maker of last resort. 2024 WL 4438249, at *7. The parties’ remedies filings evidenced significant disagreements over such issues, including (among other things) the mechanism for disseminating and updating the Play Store catalog; the installation flow for apps in Google’s catalog from third- party stores; the method of displaying third-party stores in the Play Store; the installation flow for third-party stores from the Play Store; and the adoption of eligibility criteria, policies, and fees for both Catalog Access and Third-Party Store Distribution. See, e.g., Dkt. Nos. 982-2 (Google’s Proffer), 986-2 (Epic’s Response), 996 (Google’s Supplemental Response). The Proposed Modified Injunction significantly reduces the scope and magnitude of these implementation disputes by adopting an agreed-upon approach that would directly “lower the barriers for rival app stores to get onto users’ phones,” which was the purpose of “enjoining Google from prohibiting the presence of rival app stores in the Google Play Store.” 2024 WL 4438249, at *7. This approach will reduce the need for “continuing supervision” by the Court. NCAA v. Alston, 594 U.S. 69, 102 (2021). To be sure, the parties may come to disagree on certain aspects of the implementation of the Registered App Stores remedy, and the Proposed Modified Injunction preserves the Technical Committee to resolve such disagreements in the first instance. But those disagreements will be narrower and less complex than those that were likely to arise in implementing Catalog Access and Third-Party Store Distribution. The Proposed Modified Injunction, and the Settlement it enables, also address a limitation of the Catalog Access and Third-Party Store Distribution remedies arising from the territorial scope of the Existing Injunction. In Epic’s view, because the Existing Injunction applied only to the United States, even when those remedies were in full bloom, third-party app stores would still face challenges in building the scale necessary to compete vigorously with the Google Play store, with its global footprint. If the Court adopts the Modified Injunction and the Settlement goes into effect, however, the Registered App Store program will result in changes to the Android operating system worldwide, thereby strengthening competition across Android, including in the United States.

Basically as per the new settlement, the previously suggested remedies of Catalog Access (other stores being able to distribute apps that are hosted on PlayStore) and Third-Party Store Distribution (PlayStore hosting Third-Party stores itself) have been replaced with the new Registered App Store remedy.

As per the Registered App Store remedy, future Android versions will allows users to install Registered App Stores with a single screen, and then will allow such stores to manage installs and downloads of other apps hosted on it, and the flow will be similar to downloading apps from the Play Store. Likely this means registered stores would be able to request the INSTALL_PACKAGES permission instead of the REQUEST_INSTALL_PACKAGES permission, and they would be allowed to install (not just update) apps without the package installer app user prompt, like it currently isn’t shown for updates if a store has UPDATE_PACKAGES_WITHOUT_USER_ACTION permission on Android >= 12.

The Registered App Store remedy looks to be a great step forward to maintain openness of Android by Google. However, there are currently still some concerns regarding the following part.

To address Google’s view that app and app store downloads could be used by bad actors as a vector for fraud or malware, the parties have also agreed that Google may apply specified neutral safety and security criteria to review stores for certification as Registered App Stores. That process is conceptually similar to a remedy proposed by Epic’s expert at trial. (See Trial Tr. vol. 11, 2156:25-2163:2, Nov. 21, 2023, Dkt. No. 844 (“Android is going to check to see if the app bears that notarization sort of stamp of approval. If so, Android does not show that friction screen . . . .”).) Google will be permitted to charge reasonable fees to cover the operational costs of this review process. And the Technical Committee can provide guidance on any implementation questions relating to this remedy.

1. The stores that want to get registered would need to be certified, which is expected, but the conditions are currently unknown. If they are too complex or they require too many resources/money/monitoring, then smaller stores (maybe even F-Droid) may not be able to fulfill the requirements or may not want that responsibility.
2. Who will do the certifications, is it Google, someone in the US or device vendors? If that is Google or someone in the US, then the Will Google block apps of developers from specific countries?, Will Google block apps of developers that are engaged in court disputes with Google and other US companies, or competitors of US companies? and Will this be used for policing Android developers worldwide? sections still apply to developers of the app stores.
3. Since changes are to be added in future Android versions and it will not be possible to grant INSTALL_PACKAGES or change flow of installation on older Android versions, how will this affect the certification process. Will changes in Google Play Protect being added for developer verification backward compatibility also be used for approving installation of registered stores.
4. How does the settlement affect the Android Developer Verification requirements? Will Registered App Stores be responsible for apps on their own stores, or will apps both on Registered App Stores and distributed outside them still need to get verified by Google?

Note that a lot of open source apps are distributed from GitHub, GitLab and other source code hosting sites, and those are not “App Stores”, and apps distributed on them will still need to be installed via the browser/file manager apps.

So there should still be some way (like as proposed) for non-registered stores to be installed, and apps on them and apps outside any stores to be installed with normal install mechanism like it currently is on Android <= 16, without developer verification and without root/adb.

How will limited distribution work for hobbyist/students?

I’m just a hobbyist/student. What is “Limited Distribution”? We understand that not everyone is a professional developer. We are introducing a free developer account type that will allow teachers, students, and hobbyists to distribute apps to a limited number of devices without needing to provide a government ID. Last updated: Sept 11, 2025

NAHEED VORA: So I think the only thing is you need to bring an email, and that’s about it. And it’s that simple. It’s as simple as that. TOR NORBYE: Isn’t that a major loophole then for a bad actor to say, yeah, yeah, yeah, I’m only going to share with my friends. But then actually, do we have a way to count? How do we make sure that it isn’t going to be mass distributed? NAHEED VORA: Yeah, so I think the way we have been thinking about it is that number of devices that you can install on would be limited. TOR NORBYE: So when I install, that gets counted? PATRICK BAUMANN: The way that we’ve been designing this piece of it is that you as a user, if you would like to get software from someone who’s in this program, you give them an identifier from your device. There’s a unique identifier that we’re generating specifically for this purpose. There’s kind of a back and forth established relationship with the developer. TOR NORBYE: OK. So the actual publishing part is different? NAHEED VORA: That’s right. It’s just the two way handshake that, hey, that user understands. And you as a developer can send an invite. They can throw back a token that you put in the Console. And then from there, you can go and send them apps to install on their device.

How will ADB work?

Will Android Debug Bridge (ADB) install work without registration? As a developer, you are free to install apps without verification with ADB. This is designed to support developers’ need to develop, test apps that are not intended or not yet ready to distribute to the wider consumer population.

For people saying not to worry, adb will still work, in Google’s own words, adb is considered to be used for “test apps that are not intended or not yet ready to distribute to the wider consumer population”, that means it is not meant to be used as a normal install mechanism for “release” apps that are distributed by stores like F-Droid or GitHub for consumers. It also means limits could be put in place in future on number of installs, just like they are for hobbyist/student.

This view is also confirmed from the Android developer verification video:

RAZ LEV: If you’re going to install it on your own device using ADB... then you’re not going to need to verify... If you want other people to use it, then you’ll need to verify because now other entities are involved. We want to keep those people safe.

RAZ LEV: But there will be backwards compatibility leveraging Google Play Protect. And that’s going to have slightly different behaviors in some cases, just because of the difference between a native verifier in the operating system versus leveraging an existing APK. But the goal is to give global coverage to all Android devices.

Verification is going to be backported to all android versions, and adb wireless only works for Android 11+, and requires a usb connection from PC on older android versions on every reboot, and often has device driver issues. While Termux users using developer options are partially expected to be developer minded to be able to run shell commands, normal app users who install normal apps from stores are not. Additionally, people still on older Android versions are more likely to not own secondary devices like a PC to be able to run adb commands anyways.

And if Google still suggests using adb for sideloading, will they then stop approval of apps on PlayStore (like bank/food apps) that refuse to work if Developer Options is enabled?

Are sideloading and other stores going away?

MATTHEW FORSYTHE: Well, I think sideloading, I think, is one that comes up quite a bit. And I do think it’s one that maybe is not as understood as well. And so I think, as you mentioned before, sideloading isn’t going anywhere. It’s very much core and central to Android. I think just to be really clear and put a fine point on it, developers will be able to distribute their apps through sideloading or other stores as long as they’re verified.

If all other stores need to get approval from one single store/company on most Android devices (apparently >90% of all Android devices outside China), then there is basically only one store. Google shouldn’t simultaneously both be the owner of the primary store and also the only verifier of all other stores on almost all devices.

Why is there a $25 fee?

Why is there a $25 fee for the ADC? How can I pay? The $25 fee for the Full Distribution account in the ADC helps cover administrative costs and investment in protecting the ecosystem, similar to Play’s $25 registration fee. We are actively working to support multiple forms of payment to accommodate developers globally and will have more details when the console launches. We are waiving the fee for developers who qualify for a Limited Distribution account. Last updated: Sept 3, 2025

Google won’t be able to receive money from restricted countries. And developers in approved countries do not have always have payment methods available to pay for services themselves, even if Google supports them. This is a common problem for developers who want to pay for a VPS, etc, who are in China/Russia, etc, including our own Termux team.

All developers would also need to be above 18 years of age since money and contracts are involved.

• https://support.google.com/googleplay/android-developer/answer/6112435

More reasons below why there is a $25 fee:

TOR NORBYE: Speaking of the Play Store, so you mentioned earlier that we had done this already and we had good results. Can you share more about what those good results were? What data did we see that concluded that, well, this is actually the way to go? RAZ LEV: I don’t remember the numbers off the top of my head, but we’ve seen double digit reduction in bad actor activity on the Play Store. It just became too difficult for them. The way that a lot of the bad actors operate in these type of marketplaces is they create a lot of accounts. And by a lot, I mean, huge numbers, thousands, tens of thousands, hundreds of thousands. So when you think about a legitimate developer that says, hey, $25, that’s a big fee. And I need to give my ID and that’s difficult. Now imagine somebody having to do that tens of thousands or hundreds of thousands of times. It becomes really, really difficult. And even if you do it, it’s very difficult to do it in a way that is unnoticeable. So you do it, and all these issues start showing up. And that’s really turning our attention to these accounts. And then we can take care of them. And those bad actors don’t monetize. They don’t earn money. It’s more difficult for them to sustain these operations. That’s been going on on Play for a while. And we’re very happy with how it’s working.

How will registering existing and new package names work?

TOR NORBYE: Is this going to be like handles on new social media sites, where there’s a land grab? If I’m early, can I grab com.facebook.messenger? RAZ LEV: We’re not going to let you do that. So we’re going to put in place governance for existing APKs. For future APK names, you will be able to grab whatever names you want. TOR NORBYE: So there’s no namespacing with– if someone else has a package name, can I grab something similar to it? Do we do any kind of limitation there? RAZ LEV: No, we don’t. We’ve actually given it a lot of thought. And the package names are not really visible to users. So grabbing a package name doesn’t give you a huge advantage. You can anyway pick– TOR NORBYE: I see it in the Play Store URL. RAZ LEV: You’re right. You see it there. And some stores show it in a pop up when you download an app from them. But it’s pretty hard to find it and you need to be very mindful to look for it. The thing that really matters is the app icon and the app name that shows up on the device. And we’re not going to start managing those. The situation stays as it is in Android.

Basically open source “forks” of apps with same package name won’t be able to register themselves, unless the original owner who already had the app on PlayStore registers for them. This applies for Termux too for F-Droid/GitHub releases.

How will signing challenge work?

Android Developer Console will provide you with a snippet which you need to copy and add to an APK’s asset folder. You’ll then need to sign the APK, and upload it in Android Developer Console. We’ll provide a sample project so you can see the required file structure. This APK is used only for the purpose of verifying ownership, and you won’t need to upload the actual APK that you distribute.

I assume the private key needs to sign an APK instead of a text file so that apksigner can be used and normal build process can be used. Will there be an expiry on the token in case it will take time for the developer to sign it, like some formal process of signing in an air-gaped machine, etc, like F-Droid which normally takes 3 days to manually sign.

• https://gitlab.com/fdroid/wiki/-/wikis/FAQ#signing

How will verification work at install time?

PATRICK BAUMANN: In the operating system, we built a hook into the install flow. So any kind of install has to go through this verification. At the time of install, we reach out to a trusted entity on the device, the developer verifier. It’s a preloaded app that has– it’s exclusive, so there’s only one on the device. So there’s a single trusted entity that we ask whether or not there’s a verified developer behind a package that we’re installing. We’ll pass the package name and the hash of the signing key as the identifier for it. And then we’re told by the verifier, both whether or not it was verified if it runs into any issues while verifying, and then what policy we should enforce. TOR NORBYE: OK. So my phone has to be connected in order to install an APK? PATRICK BAUMANN: In the worst of cases, yes. TOR NORBYE: OK, what is the best case? PATRICK BAUMANN: So in the best case, you hit a cache. So this trusted entity, the developer verifier, can build all sorts of things on top of that basic back and forth. They’re building a cache of– to be determined what will be contained in it, but presumably, popular apps.

There is more information regarding this in the Internal Implementation section below. The verification check is made on all installs, even updates in case developer was previously verified, but is not verified anymore.

There’s also a pre-auth– we call it a pre-auth token. It’s basically a cryptographically verifiable blob that is associated with the package that’s being installed that the installer can pass in alongside the app and verify the developer without having to hit backend. So if you’re installing something from a store, as long as they can get the bytes for the APK, they can presumably also get the bytes for the pre-auth token and avoid any additional network back and forth.

So it should be possible to install “approved” APKs without an active internet connection. Possibly backup apps can also backup the pre-auth token and use it during restore. All old backups created without this pre-auth token will not be restorable, unless adb or root is used, so users will have to create new backups and backup apps will need to add support for using pre-auth token.

• https://developer.android.com/reference/android/content/pm/PackageInstaller#DEVELOPER_VERIFICATION_FAILED_REASON_NETWORK_UNAVAILABLE

How will enterprise devices work?

TOR NORBYE: Any other complaints, or misunderstandings, or legitimate complaints maybe that you’ve heard? NAHEED VORA: There are some nuances about certain scenarios. Maybe I don’t know if you want to talk about enterprises and their apps, perhaps. RAZ LEV: Yeah, we can mention that quickly. So Android is very big and used by a lot of people. And over the years, many, many, many use cases have been built over it. And such a big fundamental change is making some of these very niche solutions either not work or require some adaptations. So for example, entities that distribute apps on devices that are not connected to the web in any way are going to need to figure out how to either leverage the tokens that Patrick mentioned or create a connection once in a while to get the permissions. We’ve made exceptions for enterprise management solutions. In an enterprise setup, there is an IT admin. And it’s their responsibility to vet the apps that their users are installing. So if someone’s using an enterprise management solution, they would be able to install apps that are not verified.

How will verification affect F-Droid and other stores?

F-Droid and other stores would have to register the signing keys of their own store APKs with Google, and if Google doesn’t approve them or revokes them in future, users won’t be able to even install the store itself, let alone the apps on the store (unless browser is used). So either the store app will need to be preinstalled on the device by the vendor or users would need to use adb.

The Epic Games Inc vs Google LLC case settlement requires Google to add Registered App Stores support in future Android versions, but not all stores may get registered.

Note that Google PlayStore currently also does not allow apps of other stores on it as it violates its policies, that’s why F-Droid store is not available on Google PlayStore either.

4.5 You may not use Google Play to distribute or make available any Product that has a purpose that facilitates the distribution of software applications and games for use on Android devices outside of Google Play.

• https://f-droid.org/docs/FAQ_-_General/#why-isnt-f-droid-on-google-play
• https://play.google/developer-distribution-agreement.html#4.-use-of-google-play-by-you

How will verification affect apps on F-Droid and other stores?

F-Droid has published their responses at following links. There are lot of other stores too, like Samsung, Epic, and lot of chineses ones belonging to xiaomi, huawei, tencent, etc.

• https://f-droid.org/en/2025/10/28/sideloading.html
• https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html

F-Droid by default signs APKs themselves in an air-gaped machine and does not give access for private keys to developers, but it does support developers to sign with their own keys since 2023 if they can get reproducible builds working, or host their own repo. From my older quick check, of the 8000 apps on F-Droid store main repo, only ~700 were being singed by developers themselves.

• https://f-droid.org/2023/09/03/reproducible-builds-signing-keys-and-binary-repos.html
• https://f-droid.org/docs/FAQ_-_App_Developers/#what-about-signing
• https://gitlab.com/fdroid/wiki/-/wikis/FAQ#signing

What this means is that developers who have been releasing apps on F-Droid will not be able to complete the dummy APK signing challenge required for developer verification to prove that they own the private key.

F-Droid cannot register themselves for all package names themselves because:

1. They do not own the package name/reverse domain name, that belongs to the developers.
2. If a developer is also releasing the app on PlayStore, they would have already registered the package name in their own account.
3. If F-Droid registers all package names on behalf of all developers, and if one of the package gets flagged to contain malware, all package names would get blocked and won’t be installable anymore as F-Droid’s identity would be flagged.

One way to solve this issue is if F-Droid were to provide some portal for developers to submit dummy APKs with tokens that they then sign with the private key on behalf of the user. Of course that would requires some kind of authentication mechanism so that only developer team themselves can submit the request instead of some random person trying to take over the registration of the package in PlayStore. F-Droid itself does not have user accounts currently where developers registers and requests to add packages are just sent on gitlab via issues/pulls. Maybe domain emails or gitlab accounts itself could be used and since hopefully Google generates a unique token for every user trying to register a package, the dummy APK submitted to F-Droid by owner developer cannot be used by someone else even if posted publicly online. This could of course lead to problems where different members of the same app project try to take over PlayStore registration by asking F-Droid first if app is not already on PlayStore, so F-Droid will need to set up some policy.

• https://gitlab.com/fdroid/fdroiddata

F-Droid keeping private keys themselves and not giving access to users is not a F-Droid specific issue, Google PlayStore does the exact same thing with “Google-generated app signing key”, which is used for 90% of all new apps, which then begs a question. If Android supports custom VerificationServiceProvider (check Internal Implementation section below), then how will developers on PlayStore register their package names on other service providers if they don’t have access to the private key. So Google will also need to implement a similar portal to sign dummy APKs with the private keys they themselves are keeping. So is Google going to implement such a portal? If not, then PlayStore apps will not be installable on such devices with non-google verification service providers and vendors would be forced to either use Google verification service provider, or at least still have it installed on the device to call its service from their own service provider as a fallback assuming that’s supported by calling DeveloperVerifierService.onVerificationRequired(DeveloperVerificationSession) without going through PackageManagerService.

• https://support.google.com/googleplay/android-developer/answer/9842756

How will this affect Termux app?

It will be DEAD! Well, might be.

Termux currently distributes com.termux package on 2 sources officially from termux GitHub org (https://github.com/termux/termux-app) and both have a different signing key:

1. F-Droid: Termux team does not have access to the private signing key and only F-Droid does.
2. GitHub: These are debug builds and used by users who want to use latest features on master branch before releases are made, or want to send pull requests, or want to use adb shell run-as com.termux to run Termux commands from PC. The private key for this is public as developers and contributors need to be able to develop locally and test pull requests without having to uninstall/reinstall a differently signed APK. (https://github.com/termux/termux-app/blob/master/app/testkey_untrusted.jks) These builds are also heavily used by our users and there are currently 3 million+ downloads for our last major 0.118.0 release.

Additionally an experimental fork of the com.termux package is also distributed by the original creator of Termux app on PlayStore from his own termux-play-store GitHub org (https://github.com/termux-play-store/termux-apps) and Termux team in termux GitHub org neither has access to termux-play-store org or the Termux app PlayStore account. Only the original creator has access and he hasn’t transferred the access to termux org yet, and it does not seem like that will change. For some more info on this issue, check termux/termux-app#4000. The PlayStore release also has its own signing key.

So how will this situation affect Termux:

1. F-Droid will need to provide a portal to sign the dummy APK, if it does not then Termux will not be installable anymore from F-Droid. Even if F-Droid does provide a signed dummy APK, the termux org will not be able to register it, as we do not have access to the PlayStore account, and it will require the original owner to submit the signed dummy APK on our behalf.
2. GitHub releases private signing key being public can be an issue for Google, I do not see anything mentioned regarding it in the docs. Other open source projects would also be using public keys. If Google does not allow private keys being public, which is likely as private keys are meant to be tied to individual identities, then Termux will not be installable from GitHub either. If Google does allow it, it will also require the original owner to submit the signed dummy APK on our behalf.

However, the original creator registering signing keys on behalf of termux org is not viable as that will give them exclusive control over F-Droid and GitHub too, in addition to PlayStore. We very likely will not be able to register our own signing keys of the com.termux package ourselves from a different account as the original Termux app has existed on PlayStore since 2015 published from the original creators account. So unless original creator transfers the PlayStore account and termux.com domain to termux org, the termux org team will just fork the Termux project and start anew, which will be months of work for us, not to mention millions of users will need to shift.

Which then leaves two possible outcomes:

1. The PlayStore account gets transferred to termux org and then we are able to register existing F-Droid and GitHub signing keys, depending on if F-Droid provides a portal and Google is okay with the publicly available private key. If either key does not get registered, users will need to backup their termux app data with tar/termux-backup and install an APK whose signing key was approved, and restore data on new install. If neither key gets approved, or even regardless, we already had created a new signing key that was to be used for releasing APKs from our site/custom F-Droid repo, etc, so we can register that, its signing key will not be publicly available and users can shift to that build.
2. The PlayStore account does not get transferred to termux org and we fork, in which case users will run into issues. The termux native (apt) packages are compiled specifically for the /data/data/com.termux path that Android by default assigns to the com.termux package for its app data directory, and the packages will not work if restored in an app with a different app package name as app data directory path will be different. However, I am in the process of implementing dynamic variables, and if it works, then it should be possible to restore a com.termux native packages backup in our forked app, but there could still be issues. I have already implemented the new shell environment from the app side required for it as part of termux-app rewrite, but changes to libtermux-exec.so $LD_PRELOAD library still needs to be implemented. If it does not work, then our millions of users will have to install all packages from scratch and setup their environment again, which would be insane amount of work overall for all our users, not to mention us having to deal with the insane amount of support issues created by users for it. Note that while Dynamic Variables design can be used to run com.termux packages in another app package, there will be a runtime cost due to $LD_PRELOAD hooks, I haven’t tested how much.

• https://termux.dev/en/posts/general/2024/11/11/termux-selected-for-nlnet-ngi-mobifree-grant.html#dynamic-variables
• termux/termux-packages#24407 (comment)
• https://github.com/termux/termux-packages/wiki/Termux-execution-environment

By not installable, I mean by normal install mechanism, adb would still work, unless max install limits are added in future.

Note: The private signing key being publicly available for GitHub releases is not really a security risk for Termux since if someone has access to the device, they can just open the terminal to access all of the Termux data without having to install a malicious APK like the case of other apps, or use the Termux SAF provider. A malicious APK from random sources could also be installed over current installation, but a user can just download malicious code directly inside Termux itself instead of installing an APK. Our users are already warned in our install docs to not install Termux APKs from random sources.

Termux’s situation is unique partly, because of pre-existing PlayStore issues and Google is not to blame for it all, but this verification requirements will just exacerbate the situation, and the F-Droid/GitHub issues still apply to most other open source apps too. I still wanted to mention our situation to let Google be aware of it, and also allow other open source projects to prepare themselves who may have similar issues, and also for our users who would/have been curious about future of Termux too.

How will this affect Open Source apps?

Open source apps primarily have 2 issues.

Shared Package Names

Open source apps share package names for forks. Forks might either be done for two reasons, for sending pull requests to upstream, or to maintain an independent project fork of upstream.

For sending pull requests, verification requirements shouldn’t affect anything as adb can be used, unless max install limits are added in future. But it can affect independent forks, as normal consumer user will need to install the apps with normal install mechanism and not only developers with adb. If forked app developers won’t be able to register their signing keys, then normal users won’t be