I mostly use apps installed from F-Droid, so I’m not sure how I’ll use the phone, except that it’s sometimes required as a contact method.
I’ve been using GrapheneOS for a while, which should minimise disruptions, but I’m also hoping the Linux phone ecosystem improves before Google locks down Android completely.
Same. I have to imagine there are some devs out there who will start working on Linux ports of their apps.
DeGoogled Custom ROMs
Keep waiting for a Linux phone that actually works as a daily driver.
At that point I’d rather use a half functioning Linux phone than a locked down one. Hopefully stuff like Framework and Fairphone will follow through on making parts available for real old devices.
Continue using a custom ROM.
If more brands start locking down their devices I’ll have a conundrum, and it’ll start being about antique hunting. More apps requiring an “approved” OS would also do it, but geopolitics will stop that from going too far in the near future.
If it really interferes, same thing as when YouTube started enshittifying: use it less and likely be better off.
I don’t have to do anything. I use GrapheneOS btw.
The problem for all these things is proprietary firmware.
What problem? Firmware for my phone works fine.
The firmware is made by the phone makers, and partly needs to go into the ROM. And if they don’t make it available, you can’t run Linux on them.
For example, on some phones in order to install Sailfish, you need to update Android first. Plus, that firmware is usually proprietary and not available as source code.
It is easily conceivable that smart phones become so locked down that it is not possible to install something else.
I feel embarassed to say this as someone who is fairly techy, but I’m a little confused by the whole brouhaha.
Is Google making changes to Android, or to AOSP?
If Google is making changes to the Android fork they put on their own phones, then fuck 'em. Use Graphene. Use e/OS/, use Lineage…use something that forks their own branch of AOSP and Google can pound sand because those forks are in no way obligated to make the same changes as Google. AOSP is open source for that very reason.
If Google is making those changes to AOSP itself, which means that anyone who uses AOSP as a base have those changes by default, then isn’t Google obligated to keep those changes as Open Source, in which case anyone else who uses AOSP can just remove them from their own fork?
Someone explain like I’m a particularly dim five-year-old, please.
If you want to keep using google playstore and services, you no longer will be able to use f-droid, whether google or any aosp rom. grapheneOS claims it won’t be affected given their sandboxed google play and services. Though I’m not sure if eventually google would come up with a counter measure or it won’t ever care. They want to enforce that if anyone uses their proprietary stuff the apps interacting with it must be from register developers, which automatically exclude any libre/free app storage on which developers don’t want to register to google. GrepheneOS being the exception.
If you use microG with any custom rom, I guess that might work through fake registrations, but can’t be sure. But any custom rom without google play and services is supposed to be ok with f-droid. The thing is that google knows most if not all users need one app that depends on their stuff, perhaps bank apps, payment apps, and so on…
iirc they are enforcing this on the play services level, using the play protect system. so if you use a custom rom with google play, you are likely cooked too.
that is if the roms don’t implement a system to circumvent it.
I’ve also been confused about this, but this is my take on it.
You’re correct that they are making these changes to Android and not AOSP. This means that an OS like Graphene or e/OS/ will still be able to use sideloaded apps and other appstores like F-Droid.
I think the reason everyone is freaking out about this, is that it hurts appstores like F-Droid. It has a chilling effect on apps that are released to alternative app stores and may cause those stores to fail over time, thus killing FOSS apps at the point of distribution.
That said, this is also over my head technically, so I would love if someone more knowledgable could weigh in.
Yes, this is an important point overlooked by the ‘But I have root’ crowd.
Also: https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html
I’ll just keep using grapheneOS.
install them with adb. its a crucial feature for developers, so they won’t easily get rid of it.
How do you get updates when installing via adb?
Install them via adb, probably
Is this manageable for the non-dev by chance? I can get by on a tutorial or too but if enough things break I’m feeling a dumbphone alt may be the only viable path
Depends on your comfort with CLI tools. Here’s the process (assumes Windows):
- Download and extract platform tools
- Add that location to your PATH
- Win + R, type “cmd”, enter
set PATH=%PATH%;C:\your\path\here\<- Temporary, just for the current sessionsetx /M path "%path%;C:\your\path\here\"<- Permanent
-
On your device, go to
Settings -> Aboutand look forBuild Numberit can sometimes be buried inSoftware Information -
Tap
Build Numberrepeatedly until a message appearsYou are now a developer -
You should now have a new
Developer optionsmenu item somewhere in your settings. Sometimes it’s top level, sometimes it’s buried underAdditional SettingsorAdvanced Settingsor the like -
Make sure
USB Debuggingis turned on -
Connect the device over USB
-
Back on WIndows type:
adb devices- You might get a popup on the device asking if you want to allow USB debugging. Select Yes, and run
adb devicesagain. You should see your device listed
- Download the APK of the app you want to install (AAB files are a PITA, but can be installed too. Try to get APK files though)
- Install with:
adb install C:/path/to/app.apk<- ifadb devicesonly returns one deviceadb -s <device_id> install C:/path/to/app.apk<- specific device
You can install updates the same way, just download the updated APK and add the
-rflagadb install -r C:/path/to/app.apkSo no
Most of that stuff is automatable - except the bit about activating Developer mode and USB Debugging on the device (steps 3 to 6) which only needs to be done once per device - so I expect we will soon see several nice GUI tools that automate the rest and eventually we might even just see stuff that talks directly to the phone over USB via libusb and using the same protocol as ADB, so installing the Android Platform Tools won’t at all be needed.
But yeah, at this point it requires people to at the very least be familiar with using the command line.
Someone suggested elsewhere (I can’t remember where) that Shizuku could be messed around with to allow installation without any computer’s involvement at all, to emulate
adbon the phone itself. Would you know anything about this workaround?A quick look through its documentation shows that it instructs the user how to go through a subset of the instructions the original user provided (or an alternative set of instructions if using Android 11+ as there it can use a different mechanism) plus a few more, in order to run a Shizuku service as user “adb”.
From then on, that Shizuku service can then be used by other apps to do everything the “adb” user can, including installing and updating applications.
So I guess it could be used by something like F-Droid to go around Google’s new mechanism to close down app installs.
For Android < 11 it’s is no more non-expert friendly than the instructions already provided by the original user, though it’s better in Android 11+ as there it’s all interacting with menus on the Android side (see here under Start Shizuku)
That’s why I posted it. So people can decide for themselves. Doesn’t seem that bad to me, but then I’m a dev, so it’s really hard to judge what a non dev would be comfortable with
yes actually, it’s just not that practical.
which i think might be the entire point anyway.
No it’s not. Not because of that it’s too difficult but it’s too much work on a weekly basis just to update your stuff.
I have no rooted phone because I have grapheneos but it should be possible to do it directly on your rooted phone with shizuku et al which wouldn’t be that bad.
How’s graphene been serving you? I’ve wanted to take the plunge for a while now and this no side loading bs has me looking into it again
Can just confirm the other comment
GrapheneOS is serving me very well
No problems (currently) with banking apps eitherI’m very happy with it - although a real Linux phone would be really cool
Gos is good. It is a solid os. I like it a lot. I have a lot of freedom that I don’t have on other phones. But it is also just android. other brands like samsung added a lot of goodies to their os. It is a phone, it works, it’s alright. It took me a while to understand that graphene’s exploit protection slows down apps. I disable that for all important apps like osmand where speed is crucial. Osmand is still slower than on an iphone 6. Do I have to use it security wise? No, but I like supporting it. Will my next phone have gos as well? Yes. It has no annoyance on it. There is no unwanted app or anything. That’s amazing.
There is also Shizuku that might be utilized in der Future to install apps (Im just speculating here)
Yes it is.
It will probably be something similar to ios altstore. You would have an app which has a list of your non-playstore apps and repo for their releases and would notify you for upgrades that you would manually have to install (for example I suppose obtainium will implement adb), the setup will be annoying but far far less cumbersome than apple where you have to reboot your device multiple times self sign ipas and refresh once a week otherwise the apps don’t load at all. This iOS experience is awful but still doable and non-dev. Android will have a better experience for sure.
Is this manageable for the non-dev by chance?
Not really.
I’ve not been following things super closely, but the idea would be that each user would get their own developer key and then locally compile and deploy whatever apps they want as though it were a project they themselves were working on. The first bit is not too dissimilar from how a lot of people with XBOXes made dev accounts to install emulators. But the latter is going to get real messy and REAL compromised REAL fast as people just use third party tools and binaries that will inevitably be compromised.
I’m feeling a dumbphone alt may be the only viable path
It really depends on what your use case is. If you actually just talk to people on phones? Uhm… I am not even sure where you would find a dumb phone at this point, but that will probably work for voice calls and SMS using just your carrier and MAYBE wifi. But anything that involves apps, which is a shockingly large part of the world, will be a mess. Some you can (and should) do workarounds (banking apps, for example) but others you are kind of up a creek since your options are to use a modern phone or not be able to (for example) see your kid’s daycare schedule.
where do you get that stuff with a dev key?
sideloading is completely fine, only requirements are the tools on the pc and a cable.
I’ve seen differing reports on that one. One Q&A with a google rep that made it sound like android studio (? The IDE/toolkit) could still do whatever without a key but with a lot of vague reference to other modes and programs.
Which, to me, reeks of “Sooner than later, all devs will need a key”. Because if it were really that clean cut, they would be screaming it from the mountain top.
I think that goes similarily with the plan that app publishers need to be authorized to publish on play store? same as with a key. KYC everywhere
so you mean unauthorized apps wont be running on android?
that would be anyway the enshittification of android.
so you mean unauthorized apps wont be running on android?
That is indeed the plan and what is meant by “starts restricting FOSS apps” (which is an incorrect statement but whatever)
However, making that happen outside of its app store will require Google to take a page from Apple’s playbook and flex its muscle in a way many Android users and developers could find intrusive. Google plans to create a streamlined Android Developer Console, which devs will use if they plan to distribute apps outside of the Play Store. After verifying their identities, developers will have to register the package name and signing keys of their apps. Google won’t check the content or functionality of the apps, though.
(…)
Google says that only apps with verified identities will be installable on certified Android devices, which is virtually every Android-based device
What was argued was that people can basically just compile/download and deploy their own apps via development tools. Which is unfeasible for the vast majority of users for skill reasons but also, as I said, likely to be blocked by google themselves in the not too distant future.
LADB can have a phone connect to itself over ADB and install apks which are stored on the phone. Maybe F-Droid can utilize this as an installation medium.
Staying on Graphene for the time being. AFAIK should be able to still install apps whatever way I see fit.
Graphene’s team has stated that they are looking into OEM’s to potentially work out a solution to make a suitable device to run GOS, since Google is locking things down.
If it really comes to it, (long term), I’ll make the jump to a Linux mobile device, whether that’s a phone or a custom solution.
Just because corpo’s are making things difficult, doesn’t mean I’m going to cave. I started this privacy journey 6 years ago and I’m not about to undo it because of greed and inconvenience.
I’m currently using GrapheneOS on my Pixel phone I brought secondhand so think I should (for now) be okay?
Otherwise, Linux phone looks interesting but it just relearning both another OS (like iPhone users trying to learn Android and vice versa) and also just I have low income so buying new tech is just expensive.
I don’t want to throw myself a deepend to an OS that I not as familiar with beside on my desktop and Raspberry Pi. Personally, I prefer to know what’s there before I just go blind so at least I can manage my expectation than expected it to do 1:1 stuff that I do on my phone right now.
I will switch to Android roms that don’t have that defect, and continue to buy and tinker with Linux phones when I can afford it, until they become daily-drivable.
GrapheneOS
Giving more money to Google after they fucked u in the arse. Brain dead move
- In what way?
- What do you suggest, live brain dude?
Linux or bust. We need to humble these companies at any costs. Open software open hardware
This is a good idea, except that it requires money. I already have an old Pixel right here that I can put Graphene on.
I guess my point is, it’s not necessary to harass people about their choice of phone OS before you know their situation. 🤷
Okay, I’ll just install debian on my phone then, thanks for the advice.
Jesus!
Which phone do you suggest then? Like I ALSO have a Librem 5, it’s just a lot of quirk. Its also not an answer to someone with an Android phone already unless they just have extra money for it. Hopefully we see better Android emulation on Librem type phones though and that gap closes.
Build a time machine and go back in time to stop WebOS from being sold to HP.
You mean convince more people to not buy android phones. Man we used to be able to run custom kernel code on the palm pre to try and get more performance out
I’ve started donating to PostmarketOS this month, so hopefully I’ll be able to buy a device with decent support once my current phone needs replacing.
I already run LineageOS on my phone with microG instead of Gapps, so not much is going to change for me. There’ll also be an update to Android 16 for me soon, LineageOS just announced that last weekend.
I don’t like android 16. I already regret so much updating to Android 15 a few weeks ago: it’s onky feature was making notifications huge and replace the monochrome logos with rhe app icon (which is not the one I have on my themed launcher) so it takes more space and is uglier. Same for the new control center: I had to disable it. Horrible locked screen experience too with less icons on top left and ios inspired dynamic island gimmicks.
Android 16, will be some design choices which are even less customizable I feel (but at least way better than ios broken transparency)
