8 ms·

A theoretical way to circumvent Android developer verification

196 points by sleirsgoevy 11mo ago

gruez 11mo ago
Sounds like the UEFI shim loader that's signed by Microsoft but can load an arbitrary EFI executable (with some signing checks). The difference is that the UEFI shim loader is endorsed/condoned by Microsoft. What about Google? This seems easily patchable, ostensibly for "security purposes" (eg. disabling loading dynamic code).
- p_l 11mo ago
  Microsoft also forces manufacturers to provide an option to reset Platform Key aka SecureBoot "root of trust" key - which is supposed to be not possible in spec-compliant UEFI system. They don't do it out of goodness of their hearts, which is why it's more solid than relying on goodwill - Microsoft simply has an offering that depends on that for certain high profile clients.
  - XorNot 11mo ago
    I suspect it's also a defense against antitrust law suits - lock in was how they got sued for things circa Internet Explorer. Frankly they should still be getting sued for the way Edge and Cortana are bundled.
    - leptons 11mo ago
      Then Apple should get sued for bundling Safari, and also for forcing all browser engines on iOS to use Safari - which is way worse than anything Microsoft ever did with IE.
      - torstenvl 11mo ago
        Apple does not have a platform monopoly on smartphones the way Microsoft did on PCs.
        AnthonyMouse 11mo ago
        Microsoft was convicted of monopolizing the market for IBM-compatible PCs, i.e. not Macs. Which makes a lot of sense, because you couldn't run Windows on a Mac nor MacOS on PCs from the likes of Dell or IBM, and you couldn't run third party software for Macs on Windows or vice versa. By contrast, you could run various types of Unix on a Dell, and run Windows software on OS/2 or DOS software on DOS competitors other than MS-DOS. That distinction seems like it might be relevant to the current situation.
        torstenvl 11mo ago
        This is utterly irrelevant. I don't know what point you're trying to make. It remains objectively inarguable that Apple does not have a platform monopoly on (ARM-compatible) smartphones the way Microsoft did on ("Intel-compatible") PCs.
        AnthonyMouse 11mo ago
        Are Apple's phones compatible with other ARM smartphones? Can you install Android or LineageOS on one, or install Android apps on iOS, or get iOS apps through Google Play or the Epic Games store?
        torstenvl 11mo ago
        No. Also irrelevant.
        AnthonyMouse 11mo ago
        It seems extremely relevant to the market definition that the alleged alternatives aren't actually substitutes for one another. If you have a car that runs on diesel fuel and there is only one company that sells diesel fuel, it seems like you want to claim that it's irrelevant and isn't a monopoly because there is another company of the same size that sells gasoline. Is it not relevant that you can't actually use that in your car?
      - jcelerier 11mo ago
        Yes
asimops 11mo ago
While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task if Google would want to go that route.
- closeparen 11mo ago
  The same EU that's doing Chat Control?
  - rf15 11mo ago
    The same EU of which parts are trying to make chat control work and are once again abandoning it. Politician get this particular fancy idea every other year in all kinds of countries, not just EU. Overreach out of desperation for a problem that cannot simply be solved is wrong but understandable.
    - igor_akhmetov 11mo ago
      Desperation for what exactly? More control?
      - ForHackernews 11mo ago
        They are trying to stop crime, including sex/drug trafficking and child exploitation. If you want to have an intellectually honest debate, you need to be clear that private communication apps do make it more difficult for police to conduct legitimate investigations. You do yourself no favours painting all politicians as power-hungry caricatures.
        ipaddr 11mo ago
        So do private in person conversations. Going the route of North Korea putting two way speakers in each house would help make those conversations available to the government. Think of all of the child exploitation you could stop by removing any sense of privacy. Of course they would figure a way around this and everyday citizens would have to deal with the lack of privacy but at least they thought of the children so we should keep voting them in.
t_mann 11mo ago
> verified loader apk, which in turn dynamically loads any apk the user wants Wasn't this kind of solution considered and sort of dismissed (because of too much centralization iirc) by F-Droid (can't find the reference now)? It seems like something that's worth trying, but in the end it's just a band-aid. If it gets any traction Google will shut it down. The real disease is dependence on a duopoly of (quasi)-proprietary OS for the dominant computing platform of our time.
- kevincox 11mo ago
  I see a handful of problems. 1. The loader will just get banned. 2. The application ID and permissions are that of the loader. To have different applications with separate data and permissions you would need multiple copies of the loader. 3. You miss out on other android security features such as application signing validation for updates.
antiloper 11mo ago
This will not work because the goal of android developer verification is to prevent running Google-sanctioned code. If you actually tried to publish this, Google will revoke the signature on the loader APK.
- NewJazz 11mo ago
  Ah yes sanctioned. A word that has two opposite meanings.
  - layer8 11mo ago
    Contronyms are awesome, yet people are nonplussed.
zb3 11mo ago
Well, I'd rather verify myself with the government identity than accept a stock OS that literally woke me up with a fake message promoting Gemini despite me spending almost 2 hours turning every possible privacy-invasive setting off. To me, the attention to these verification changes seems misplaced. We need to defend the ability to unlock the bootloader, pressure Google to revive AOSP and then encourage people to switch to a more user-friendly OS. You're already unable to install what you want on a stock OS due to Android permission model treating you as a third-class citizen, after Google and OEMs.
- asimops 11mo ago
  In my opinion, the only solution while keeping Google and Apple as the developing entities is regulation. Despite that, there are some things that should not be for profit in my opinion. A good OS platform is one such thing.
  - cageface 11mo ago
    I agree but I also think any meaningful regulation is off the table for the next few years in the USA at least.
- sleirsgoevy 11mo ago
  The issue with government IDs is that they are, for all we know, not trustworthy, but everyone treats them like they are. And you know, I am not going to "verify" myself with Google with this kind of toilet paperwork. If Google decides to pull this off, then I guess reflashing to a custom ROM with this crap patched out will be a very first step I'll be recommending to anyone who cares.
  - zb3 11mo ago
    It seems you missed my main point - the whole point is to fight for this right to reflash a custom ROM, because they're slowly coming for that too. First Play Integrity, now no AOSP releases and more vendors disabling bootloader unlocking..
p1mrx 11mo ago
I suggested this a couple months ago: https://news.ycombinator.com/item?id=45084296 https://news.ycombinator.com/item?id=45084296 Android may ultimately win the arms race, but if they want to be evil, we should make their task as tedious as possible.
- neuroelectron 11mo ago
  Google doesn't need to make an argument to ban apps or developers.
andrewcchen 11mo ago
So like LiveContainer[1] which works around ios's signing requirements [1] https://github.com/LiveContainer/LiveContainer https://github.com/LiveContainer/LiveContainer
- IgorPartola 11mo ago
  Whoa that is neat! How does that not get shut down by Apple?
  - Wowfunhappy 11mo ago
    They don't allow it in the app store, so you have a chicken-and-egg problem...
    - zzrrt 11mo ago
      It works with AltStore or SideStore.
      - Wowfunhappy 11mo ago
        So you have to either live in the EU or have a helper app constantly running on a PC on your network…
cyberax 11mo ago
This "attack" is not even theoretical. Android apps can just download arbitrary binary code, mprotect(PROT_MAYEXEC) some area in RAM, link the code there, and run it. Google will simply revoke the keys for the "loader" APK. But that's fine for malware, its authors will just use the next stolen credit card to register a new account. That's also why this has nothing to do with security.
- clueless 11mo ago
  what does it really have to do with?
  - baby_souffle 11mo ago
    > what does it really have to do with? Giving google control over what code runs on $device regardless of how that code got onto the device. A revoked key doesn't care about how the APK got there...
Gander5739 11mo ago
Doesn't https://github.com/Katana-Official/SPatch-Update https://github.com/Katana-Official/SPatch-Update already handle this, and also support Xposed on top?
bitwize 11mo ago
> My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want. And a day after you release, Google will say "Oh no you don't" and unverify your app, preventing it from being installed or run. Which is you know, kind of the point of this maneuver.
immibis 11mo ago
I'm already banned from publishing Android apps through Google, but apart from that, what would stop me making a server you can upload any app to and sign it with my certificate?
- maxloh 11mo ago
  That could actually be done solely on the device. You can develop an app to sign arbitrary APKs with users' own hobbyist certificate. Lucky Patcher have done that for a decade.
  - immibis 11mo ago
    I could even just give out my certificate and private key (if I'm allowed to have one). It's not like I need it to be private. Google would probably blacklist the certificate and then we get to sue Google based on the fact they said doing this would allow the app to work, but they didn't follow through with what they said.
  - sleirsgoevy 11mo ago
    Making every user to "verify" themselves with a government ID is a no-go, because government IDs are no more trustworthy than a toilet paper.
fsmv 11mo ago
Just use adb. You can do adb wifi on device. You don't have to distribute a signed apk just sign it fresh on device.
- Retr0id 11mo ago
  This is the way. You can also do adb-over-webusb with a second device.
  - Permik 11mo ago
    With apps like Shizuku you can do the whole nine yards all locally untethered with one device :)
userbinator 11mo ago
Or you could just tell everyone out there that there are already tons of older Android devices which will never get any of these hostile updates, and if you're a developer, make sure your app runs on those older versions. Spread the word about how hostile the newer devices are, and let the lazy masses do what they're best at doing. Of course there will always be rabid bootlickers who will gladly pay to put Google's noose around their necks, but if they become the minority, and the majority just stops upgrading, it could very effectively pull control of Android away from Google. Giving everyone yet another reason to not upgrade, especially given the huge Android marketshare in poorer countries, could become a powerful force.
- Aeglaecia 11mo ago
  i thought google was going to push this as an update to play services , thus affecting all models
- Random09 11mo ago
  Good luck with unsecure phone This is clearly a bad idea.
  - selasa67118 11mo ago
    [dead]
- blueg3 11mo ago
  If this is an acceptable solution, just run a modern uncertified Android instead.
  - selasa67118 11mo ago
    [dead]
ianbutler 11mo ago
I think this means we need to rely on web technologies more. PWAs are looking pretty good on mobile devices these days and you can publish any web app you want with no reviewing authority. The web has a bunch of crazy APIs now that let you build crazy things and for everything else you're a hosted server away somewhere that can run more complex jobs. I believe devices I own should let me do whatever I want with them and I agree that the verification is BS, but I'll work around it in the ways I can which means building more for the web. If that ever drops the open pretense (since both traffic and trust authority are largely centralized and thus easily controllable) then I'll only write for self hosted linux boxes. We as individuals can only do so much. We'd need actual organization and some measure of political power to do anything more since normal people do not care about this.
- Wowfunhappy 11mo ago
  I thought Brent Simmons did a great job laying out why PWAs don't work: https://inessential.com/2025/10/04/why-netnewswire-is-not-web-app.html https://inessential.com/2025/10/04/why-netnewswire-is-not-we... The tl;dr is that a PWA implies an app which is based in the cloud. So suddenly you need a server, and you need to store user data, which means costs and dealing with privacy and security.
  - teraflop 11mo ago
    That explanation doesn't really make sense to me. If something could be built as a native app without depending on a central server, it could also be built as a PWA without a central server. You don't need to store user data centrally at all, just because it's a webapp. You can just have the clients use localStorage or IndexedDB or whatever. You still have to host the static files for the webapp itself, but that can be made very cheap. Of course, API feature parity between native and web apps is a separate issue. But the argument about server costs doesn't seem like a good one.
    - Wowfunhappy 11mo ago
      Isn't localStorage limited to 5 MB of data?
Telaneo 11mo ago
While neat, it glosses over the actual problem, while maybe not even solving it (depending on what you deem the problem to be in the first place). It solved the immediate problem today, but not in a way that's going to remain solved. I'd imagine Google would plug any major holes in their soon to be closed garden, assuming that is their intention. So this and any other fix to the problem of 'install app through not-Google Play' that goes via technical means that Google can just cover up after a month or two doesn't actually move the needle any meaningful amount. In the same vein, using adb isn't a real solution to that same problem for most people, since having to use adb is a massive jump in required effort that's going to leave all the normies behind, with only the super-dedicated willing to go through the hassle, and an equivalent amount of developer effort is going to be left behind as well, since their audience just got decimated, and they themselves might not even bother to develop something that even their dad or sister is going to bother/be able to install. Anything that's much more complicated than 'go to website, download thing, run thing, click your way through' doesn't solve for this. The actual problem is to have Google not be knobheads about it, and the only way that's realistically going to happen is through the law, but that's not looking all that likely in my view.
numpad0 11mo ago
> My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. Right back to Symbian signed AppTRK and rolling back hardware clocks. Great.
whatshisface 11mo ago
>My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want. Google's not going to let you keep your signing key if you do this with it.
fifticon 11mo ago
these holes will be closed and turning into flaming jumping hoops, so this is not viable. fight the people designing the game.
nacozarina 11mo ago
yeah, googs can get rekt, I’m not even
unit149 11mo ago
[dead]
charcircuit 11mo ago
>Google assures that it would be possible to install applications locally using ADB, but there are no details on this It's going to be the same as Play Protect using the PackageVerifier API. Even if won't trust that Play Protect will continue to allow adb installs, if you go to the developer options you can disable package verifiers for adb installs. >the concept This would not really work considering you can't do a lot of things at runtime. You can't create activities, you can't create services, you can't declare permissions, you can't use permissions, etc. Pretty much everything in your manifest can't be done properly. You can't really do a job faking it. You would have to declare a ton of dummy activities with all different permutations of things like launch mode, document launch mode, intent filters, etc. What you can do are things like game engines like how the android godot editor works where you aren't loading full android apps, but projects into the editor.
selasa67118 11mo ago
[dead]
Permik 11mo ago
This is actually a non-issue with tons of unnecessary fear mongering going around, see my comment here: https://github.com/enaix/apk-loader/issues/1 https://github.com/enaix/apk-loader/issues/1
- baby_souffle 11mo ago
  The OP addressed this: `adb` works ... *for now*. Other than google's pinky promise, what assurance do we have that adb will continue to work in a year or five?
  - charcircuit 11mo ago
    The settings app lets you disable package verifiers for adb installs. The settings app is part of the operating system and can not be updated via the play store. This means that Google can not update the settings app.
    - baby_souffle 11mo ago
      > This means that Google can not update the settings app. Is that app immutable? I seem to recall it being changed with new versions of android.
VladStanimir 11mo ago
I am not a app developer however from what I read on the android developer site you just need to provide some form of id, the singing key and the app id. You don't have to distribute via the app store, you dont have to get Googles permission to publish the app or have them sign it. This looks like purely app validation, we only run apps we can prove originate from the author.
- huem0n 11mo ago
  Under that logic, even if the app is "malicious" it would still be possible to install it. And thats not true, if somthing is deemed malicious, its blocked. Is app that hurts Google's dominance "malicious"? Who is it that decides what is malicious?
- m-p-3 11mo ago
  So if Google doesn't like the app in question (such as ReVanced, NewPipe, etc), they can simply target that signing key to completely disable the app on all devices, even if it's not distributed by them. Having the file signed by a relatively centralized authority makes it much easier for Google to gain control outside of their realm.
sleirsgoevy 11mo ago
What about this idea? Make a movement among the devs who are willing to distribute "legitimately" (via Google Play or "authorized" sideload), to sign their apps with intentionally insecure private key. Then some community will just mine up these certificates in already published apps and publish them somewhere on GitHub.
thr0w4w4y1337 11mo ago
LlamaLab's Automate has a non-root privileged service via network adb service. Would it be possible to simplify app installation via adb the same way? An app that reads apk, sends it over pre-paired ADB. Sounds like a much simpler solution.
SiDevesh 11mo ago
Isn't a better solution here to build an app that signs unsigned apks with the end user's self provided signature ?
codethief 11mo ago
> So an apk may just load some zip/apk/dex code from external storage and execute it in current context. Wouldn't this break all kinds of things, like app sandboxing, the permission system, app intents, …?
- iggldiggl 11mo ago
  … launcher shortcuts, launcher widgets, storage management, multi-process set-ups or even services (those need to be declared statically in the manifest), so yeah it would. So interesting as a fun exercise, but not really useful for probably quite a few apps.
jchw 11mo ago
The more I think about all of this nonsense, the more I wonder if Google's entire goal with this is actually to kill ReVanced, of all things.
marcprux 11mo ago
This is a neat hack, and I don't want to diminish the effort. But I fear that any such loader apk would be marked as malware by Google and nuked by Play Protect Services. And as others mention, using adb (or Shizuku) might also be a workaround for tech-savvy users (for the time being). We list some other potential temporary workarounds at https://keepandroidopen.org https://keepandroidopen.org. But none of it is viable for the other 99%. There's really no solution to the dilemma other than stopping Google from implementing it altogether. And for that, we need regulatory action — which means we need to advocate and educate consumers and lawmakers about the threat that this poses.

196 points by sleirsgoevy 11mo ago

gruez 11mo ago

Sounds like the UEFI shim loader that's signed by Microsoft but can load an arbitrary EFI executable (with some signing checks). The difference is that the UEFI shim loader is endorsed/condoned by Microsoft. What about Google? This seems easily patchable, ostensibly for "security purposes" (eg. disabling loading dynamic code).

p_l 11mo ago
Microsoft also forces manufacturers to provide an option to reset Platform Key aka SecureBoot "root of trust" key - which is supposed to be not possible in spec-compliant UEFI system. They don't do it out of goodness of their hearts, which is why it's more solid than relying on goodwill - Microsoft simply has an offering that depends on that for certain high profile clients.
- XorNot 11mo ago
  I suspect it's also a defense against antitrust law suits - lock in was how they got sued for things circa Internet Explorer. Frankly they should still be getting sued for the way Edge and Cortana are bundled.
  - leptons 11mo ago
    Then Apple should get sued for bundling Safari, and also for forcing all browser engines on iOS to use Safari - which is way worse than anything Microsoft ever did with IE.
    - torstenvl 11mo ago
      Apple does not have a platform monopoly on smartphones the way Microsoft did on PCs.
      - AnthonyMouse 11mo ago
        Microsoft was convicted of monopolizing the market for IBM-compatible PCs, i.e. not Macs. Which makes a lot of sense, because you couldn't run Windows on a Mac nor MacOS on PCs from the likes of Dell or IBM, and you couldn't run third party software for Macs on Windows or vice versa. By contrast, you could run various types of Unix on a Dell, and run Windows software on OS/2 or DOS software on DOS competitors other than MS-DOS. That distinction seems like it might be relevant to the current situation.
        torstenvl 11mo ago
        This is utterly irrelevant. I don't know what point you're trying to make. It remains objectively inarguable that Apple does not have a platform monopoly on (ARM-compatible) smartphones the way Microsoft did on ("Intel-compatible") PCs.
        AnthonyMouse 11mo ago
        Are Apple's phones compatible with other ARM smartphones? Can you install Android or LineageOS on one, or install Android apps on iOS, or get iOS apps through Google Play or the Epic Games store?
        torstenvl 11mo ago
        No. Also irrelevant.
        AnthonyMouse 11mo ago
        It seems extremely relevant to the market definition that the alleged alternatives aren't actually substitutes for one another. If you have a car that runs on diesel fuel and there is only one company that sells diesel fuel, it seems like you want to claim that it's irrelevant and isn't a monopoly because there is another company of the same size that sells gasoline. Is it not relevant that you can't actually use that in your car?
    - jcelerier 11mo ago
      Yes

asimops 11mo ago

While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task if Google would want to go that route.

closeparen 11mo ago
The same EU that's doing Chat Control?
- rf15 11mo ago
  The same EU of which parts are trying to make chat control work and are once again abandoning it. Politician get this particular fancy idea every other year in all kinds of countries, not just EU. Overreach out of desperation for a problem that cannot simply be solved is wrong but understandable.
  - igor_akhmetov 11mo ago
    Desperation for what exactly? More control?
    - ForHackernews 11mo ago
      They are trying to stop crime, including sex/drug trafficking and child exploitation. If you want to have an intellectually honest debate, you need to be clear that private communication apps do make it more difficult for police to conduct legitimate investigations. You do yourself no favours painting all politicians as power-hungry caricatures.
      - ipaddr 11mo ago
        So do private in person conversations. Going the route of North Korea putting two way speakers in each house would help make those conversations available to the government. Think of all of the child exploitation you could stop by removing any sense of privacy. Of course they would figure a way around this and everyday citizens would have to deal with the lack of privacy but at least they thought of the children so we should keep voting them in.

t_mann 11mo ago

> verified loader apk, which in turn dynamically loads any apk the user wants Wasn't this kind of solution considered and sort of dismissed (because of too much centralization iirc) by F-Droid (can't find the reference now)? It seems like something that's worth trying, but in the end it's just a band-aid. If it gets any traction Google will shut it down. The real disease is dependence on a duopoly of (quasi)-proprietary OS for the dominant computing platform of our time.

kevincox 11mo ago
I see a handful of problems. 1. The loader will just get banned. 2. The application ID and permissions are that of the loader. To have different applications with separate data and permissions you would need multiple copies of the loader. 3. You miss out on other android security features such as application signing validation for updates.

antiloper 11mo ago

This will not work because the goal of android developer verification is to prevent running Google-sanctioned code. If you actually tried to publish this, Google will revoke the signature on the loader APK.

NewJazz 11mo ago
Ah yes sanctioned. A word that has two opposite meanings.
- layer8 11mo ago
  Contronyms are awesome, yet people are nonplussed.

zb3 11mo ago

Well, I'd rather verify myself with the government identity than accept a stock OS that literally woke me up with a fake message promoting Gemini despite me spending almost 2 hours turning every possible privacy-invasive setting off. To me, the attention to these verification changes seems misplaced. We need to defend the ability to unlock the bootloader, pressure Google to revive AOSP and then encourage people to switch to a more user-friendly OS. You're already unable to install what you want on a stock OS due to Android permission model treating you as a third-class citizen, after Google and OEMs.

asimops 11mo ago
In my opinion, the only solution while keeping Google and Apple as the developing entities is regulation. Despite that, there are some things that should not be for profit in my opinion. A good OS platform is one such thing.
- cageface 11mo ago
  I agree but I also think any meaningful regulation is off the table for the next few years in the USA at least.
sleirsgoevy 11mo ago
The issue with government IDs is that they are, for all we know, not trustworthy, but everyone treats them like they are. And you know, I am not going to "verify" myself with Google with this kind of toilet paperwork. If Google decides to pull this off, then I guess reflashing to a custom ROM with this crap patched out will be a very first step I'll be recommending to anyone who cares.
- zb3 11mo ago
  It seems you missed my main point - the whole point is to fight for this right to reflash a custom ROM, because they're slowly coming for that too. First Play Integrity, now no AOSP releases and more vendors disabling bootloader unlocking..

p1mrx 11mo ago

I suggested this a couple months ago: https://news.ycombinator.com/item?id=45084296 https://news.ycombinator.com/item?id=45084296 Android may ultimately win the arms race, but if they want to be evil, we should make their task as tedious as possible.

neuroelectron 11mo ago
Google doesn't need to make an argument to ban apps or developers.

andrewcchen 11mo ago

So like LiveContainer[1] which works around ios's signing requirements [1] https://github.com/LiveContainer/LiveContainer https://github.com/LiveContainer/LiveContainer

IgorPartola 11mo ago
Whoa that is neat! How does that not get shut down by Apple?
- Wowfunhappy 11mo ago
  They don't allow it in the app store, so you have a chicken-and-egg problem...
  - zzrrt 11mo ago
    It works with AltStore or SideStore.
    - Wowfunhappy 11mo ago
      So you have to either live in the EU or have a helper app constantly running on a PC on your network…

cyberax 11mo ago

This "attack" is not even theoretical. Android apps can just download arbitrary binary code, mprotect(PROT_MAYEXEC) some area in RAM, link the code there, and run it. Google will simply revoke the keys for the "loader" APK. But that's fine for malware, its authors will just use the next stolen credit card to register a new account. That's also why this has nothing to do with security.

clueless 11mo ago
what does it really have to do with?
- baby_souffle 11mo ago
  > what does it really have to do with? Giving google control over what code runs on $device regardless of how that code got onto the device. A revoked key doesn't care about how the APK got there...

Gander5739 11mo ago

Doesn't https://github.com/Katana-Official/SPatch-Update https://github.com/Katana-Official/SPatch-Update already handle this, and also support Xposed on top?

bitwize 11mo ago

> My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want. And a day after you release, Google will say "Oh no you don't" and unverify your app, preventing it from being installed or run. Which is you know, kind of the point of this maneuver.

immibis 11mo ago

I'm already banned from publishing Android apps through Google, but apart from that, what would stop me making a server you can upload any app to and sign it with my certificate?

maxloh 11mo ago
That could actually be done solely on the device. You can develop an app to sign arbitrary APKs with users' own hobbyist certificate. Lucky Patcher have done that for a decade.
- immibis 11mo ago
  I could even just give out my certificate and private key (if I'm allowed to have one). It's not like I need it to be private. Google would probably blacklist the certificate and then we get to sue Google based on the fact they said doing this would allow the app to work, but they didn't follow through with what they said.
- sleirsgoevy 11mo ago
  Making every user to "verify" themselves with a government ID is a no-go, because government IDs are no more trustworthy than a toilet paper.

fsmv 11mo ago

Just use adb. You can do adb wifi on device. You don't have to distribute a signed apk just sign it fresh on device.

Retr0id 11mo ago
This is the way. You can also do adb-over-webusb with a second device.
- Permik 11mo ago
  With apps like Shizuku you can do the whole nine yards all locally untethered with one device :)

userbinator 11mo ago

Or you could just tell everyone out there that there are already tons of older Android devices which will never get any of these hostile updates, and if you're a developer, make sure your app runs on those older versions. Spread the word about how hostile the newer devices are, and let the lazy masses do what they're best at doing. Of course there will always be rabid bootlickers who will gladly pay to put Google's noose around their necks, but if they become the minority, and the majority just stops upgrading, it could very effectively pull control of Android away from Google. Giving everyone yet another reason to not upgrade, especially given the huge Android marketshare in poorer countries, could become a powerful force.

Aeglaecia 11mo ago
i thought google was going to push this as an update to play services , thus affecting all models
Random09 11mo ago
Good luck with unsecure phone This is clearly a bad idea.
- selasa67118 11mo ago
  [dead]
blueg3 11mo ago
If this is an acceptable solution, just run a modern uncertified Android instead.
- selasa67118 11mo ago
  [dead]

ianbutler 11mo ago

I think this means we need to rely on web technologies more. PWAs are looking pretty good on mobile devices these days and you can publish any web app you want with no reviewing authority. The web has a bunch of crazy APIs now that let you build crazy things and for everything else you're a hosted server away somewhere that can run more complex jobs. I believe devices I own should let me do whatever I want with them and I agree that the verification is BS, but I'll work around it in the ways I can which means building more for the web. If that ever drops the open pretense (since both traffic and trust authority are largely centralized and thus easily controllable) then I'll only write for self hosted linux boxes. We as individuals can only do so much. We'd need actual organization and some measure of political power to do anything more since normal people do not care about this.

Wowfunhappy 11mo ago
I thought Brent Simmons did a great job laying out why PWAs don't work: https://inessential.com/2025/10/04/why-netnewswire-is-not-web-app.html https://inessential.com/2025/10/04/why-netnewswire-is-not-we... The tl;dr is that a PWA implies an app which is based in the cloud. So suddenly you need a server, and you need to store user data, which means costs and dealing with privacy and security.
- teraflop 11mo ago
  That explanation doesn't really make sense to me. If something could be built as a native app without depending on a central server, it could also be built as a PWA without a central server. You don't need to store user data centrally at all, just because it's a webapp. You can just have the clients use localStorage or IndexedDB or whatever. You still have to host the static files for the webapp itself, but that can be made very cheap. Of course, API feature parity between native and web apps is a separate issue. But the argument about server costs doesn't seem like a good one.
  - Wowfunhappy 11mo ago
    Isn't localStorage limited to 5 MB of data?

Telaneo 11mo ago

While neat, it glosses over the actual problem, while maybe not even solving it (depending on what you deem the problem to be in the first place). It solved the immediate problem today, but not in a way that's going to remain solved. I'd imagine Google would plug any major holes in their soon to be closed garden, assuming that is their intention. So this and any other fix to the problem of 'install app through not-Google Play' that goes via technical means that Google can just cover up after a month or two doesn't actually move the needle any meaningful amount. In the same vein, using adb isn't a real solution to that same problem for most people, since having to use adb is a massive jump in required effort that's going to leave all the normies behind, with only the super-dedicated willing to go through the hassle, and an equivalent amount of developer effort is going to be left behind as well, since their audience just got decimated, and they themselves might not even bother to develop something that even their dad or sister is going to bother/be able to install. Anything that's much more complicated than 'go to website, download thing, run thing, click your way through' doesn't solve for this. The actual problem is to have Google not be knobheads about it, and the only way that's realistically going to happen is through the law, but that's not looking all that likely in my view.

numpad0 11mo ago

> My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. Right back to Symbian signed AppTRK and rolling back hardware clocks. Great.

whatshisface 11mo ago

>My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want. Google's not going to let you keep your signing key if you do this with it.

fifticon 11mo ago

these holes will be closed and turning into flaming jumping hoops, so this is not viable. fight the people designing the game.

nacozarina 11mo ago

yeah, googs can get rekt, I’m not even

unit149 11mo ago

[dead]

charcircuit 11mo ago

>Google assures that it would be possible to install applications locally using ADB, but there are no details on this It's going to be the same as Play Protect using the PackageVerifier API. Even if won't trust that Play Protect will continue to allow adb installs, if you go to the developer options you can disable package verifiers for adb installs. >the concept This would not really work considering you can't do a lot of things at runtime. You can't create activities, you can't create services, you can't declare permissions, you can't use permissions, etc. Pretty much everything in your manifest can't be done properly. You can't really do a job faking it. You would have to declare a ton of dummy activities with all different permutations of things like launch mode, document launch mode, intent filters, etc. What you can do are things like game engines like how the android godot editor works where you aren't loading full android apps, but projects into the editor.

selasa67118 11mo ago

[dead]

Permik 11mo ago

This is actually a non-issue with tons of unnecessary fear mongering going around, see my comment here: https://github.com/enaix/apk-loader/issues/1 https://github.com/enaix/apk-loader/issues/1

baby_souffle 11mo ago
The OP addressed this: `adb` works ... *for now*. Other than google's pinky promise, what assurance do we have that adb will continue to work in a year or five?
- charcircuit 11mo ago
  The settings app lets you disable package verifiers for adb installs. The settings app is part of the operating system and can not be updated via the play store. This means that Google can not update the settings app.
  - baby_souffle 11mo ago
    > This means that Google can not update the settings app. Is that app immutable? I seem to recall it being changed with new versions of android.

VladStanimir 11mo ago

I am not a app developer however from what I read on the android developer site you just need to provide some form of id, the singing key and the app id. You don't have to distribute via the app store, you dont have to get Googles permission to publish the app or have them sign it. This looks like purely app validation, we only run apps we can prove originate from the author.

huem0n 11mo ago
Under that logic, even if the app is "malicious" it would still be possible to install it. And thats not true, if somthing is deemed malicious, its blocked. Is app that hurts Google's dominance "malicious"? Who is it that decides what is malicious?
m-p-3 11mo ago
So if Google doesn't like the app in question (such as ReVanced, NewPipe, etc), they can simply target that signing key to completely disable the app on all devices, even if it's not distributed by them. Having the file signed by a relatively centralized authority makes it much easier for Google to gain control outside of their realm.

sleirsgoevy 11mo ago

What about this idea? Make a movement among the devs who are willing to distribute "legitimately" (via Google Play or "authorized" sideload), to sign their apps with intentionally insecure private key. Then some community will just mine up these certificates in already published apps and publish them somewhere on GitHub.

thr0w4w4y1337 11mo ago

LlamaLab's Automate has a non-root privileged service via network adb service. Would it be possible to simplify app installation via adb the same way? An app that reads apk, sends it over pre-paired ADB. Sounds like a much simpler solution.

SiDevesh 11mo ago

Isn't a better solution here to build an app that signs unsigned apks with the end user's self provided signature ?

codethief 11mo ago

> So an apk may just load some zip/apk/dex code from external storage and execute it in current context. Wouldn't this break all kinds of things, like app sandboxing, the permission system, app intents, …?

iggldiggl 11mo ago
… launcher shortcuts, launcher widgets, storage management, multi-process set-ups or even services (those need to be declared statically in the manifest), so yeah it would. So interesting as a fun exercise, but not really useful for probably quite a few apps.

jchw 11mo ago

The more I think about all of this nonsense, the more I wonder if Google's entire goal with this is actually to kill ReVanced, of all things.

marcprux 11mo ago

This is a neat hack, and I don't want to diminish the effort. But I fear that any such loader apk would be marked as malware by Google and nuked by Play Protect Services. And as others mention, using adb (or Shizuku) might also be a workaround for tech-savvy users (for the time being). We list some other potential temporary workarounds at https://keepandroidopen.org https://keepandroidopen.org. But none of it is viable for the other 99%. There's really no solution to the dilemma other than stopping Google from implementing it altogether. And for that, we need regulatory action — which means we need to advocate and educate consumers and lawmakers about the threat that this poses.