The one good thing about AI video. No reason to pay “influencers” when that content can just be (crappily) generated.

Palm Pre did it first. Apple copied.

You’re under-thinking it.

In pseudo-correct but probably not order:

• Step 1: Collect underpants
• Step 2: Keep receiving Google security updates but stop updating Google mainline
• Step 3: Start replacing the underbelly to just raw Linux (or BSD or whatever) and slowly shift the “Android” portion to a VM/container
• Step 4: RIL and other stuff (probably should happen first) have to be packaged up and become their new entity on the modem side (also probably the biggest challenge, but manufacturers and ODMs provide dev kits)
• Step 5: ???
• Step 6: Once the Android side is safely firewalled away from the core OS, start embracing something like PostmarketOS
• Step 7: GUI/graphics are built out with the Android pieces still running in a container
• Step 8: Start writing applications that replace the Android applications, go one by one, remove dependence on each Android application as you go while still maintaining compatibility (I mean the core OS ones that make the device at least basically functional, the F/OSS devs will have to each rewrite/change their apps, or some other magic can be inserted here that isn’t really magic.)
• Step 9: Once the OS itself is beefed up enough, retain Android container for the needs of some for some uncomfortably long frustrating time to maintain, but not too long
• Step 10: Have Obtainium/F-Droid/etc. all simultaneously pivot and start providing apps for the native OS as well as maintaining backwards compatibility with the Android apps in the container
• Step 11: Once some magic point, forced or otherwise happens, sunset the Android portion of the app stores. Keep the containerized Android around a little longer
• Step 12: Sunset the Android container, at this point the phone should be running 100% “native” OS and apps and store
• Step 14: Profit!

There are industry blueprints for this. Apple is probably the best example of how to implement these shifts, from OS 9 (co-op MT proprietary OS)->OS X (BSD-NextStep-based Unix OS), 68k->PPC, Replacing Unix underpinnings with Apple Frameworks, PPC->Intel, OS X->iOS, Mac from Intel->ARM, etc. etc. They frequently used containerization to keep the old running while the new was built up around it and replaced. It is a solid proven design pattern.

Graphene would be better off cutting themselves off from Google’s OS future entirely and pivot the fork as quickly as possible to remove all dependencies. Probably too arrogant to consider it, though. Also becomes much more work.

Qualcomm isn’t exactly the best vendor to choose either. They’re US-based, closely-aligned with the US government as a military contractor, and the baseband/processor are heavily integrated on many chipsets, even sharing memory. That means a compromised carrier network could twiddle bits that the operating system sees, if they so wanted. Among many other issues.

There’s something about a Samsung Exynos designed to spec by Google that is actually more desirable even with the lack of compute performance. More fingers in the pot, less chance of some sneakiness working its way in.

Not trying to sound negative in tone, to prefix. Just more factual.

Need is a strong word. Browser can do banking. So can computer, tablet, the bank itself. Check deposit is one thing that an “app” is needed for but happens exceedingly rarely these days. One could also keep an old Android phone around just for that banking app if the usage was important enough. One could also go back to cash, although that has other bulky/theft issues.

Maps also can be done in browser, or open Android map apps like Organic Maps ported.

Digital wallets aren’t really “needed” in the world, there are still non-phone-based techs to replace them. Sure, it’s great having an empty pocket with nothing but a phone, but that is a pure luxury, not a need. Might actually be a good time for more people to stop using “smart” tech to keep non-smart tech in prevalence.

Remember too, all these finance-based “conveniences” are there just so every company along the way can vacuum up all your transactions. Google Wallet gets to see every card/purchase you use/do, for example, even when not using the phone for the purchase.

Fund a dev, volunteer time, and devs need to drop iOS and Android projects and focus on this.

Yeah, the hardware realm is the real difficult piece, and even if one can manufacture a device with off-the-shelf parts and manage to find chips with enough support for bands/modes for usability on carriers, getting carrier certification is a PITA.

Good luck with that too, with carriers sunsetting legacy networks, old dedicated dumbphones will no longer work in most cases. KaiOS is sometimes used on dumbphones, but most these days just run a fork of Android designed for dumbphones.

Maybe Meshtastic with an SMS API gateway is the way to go. Or cans and string.

That is an amazing dedicated ride. Kudos to your ingenuity!

Y’all, we need to get multiple break-away plans from everything big tech before it gets even more difficult.

Google hasn’t released Pixel 10 binary blobs with Android 16 AOSP, so unless they can be reverse-extracted out of Google Android and backported, Pixel 9 series will be the last to run Graphene.

They are already gone. About the only dumbphones left either run a stripped down version of Android, or pseudo-custom OSes that still have some basic telemetry, and all have GPS/etc for “e911” requirements.

Yes, although generally they have less band support than “smart” phones, and with smaller batteries the hotspot tends to kill the phone pretty fast. It might end up being a case of using a basic smartphone with no software installed and as much stuff disabled as possible as a tether source.

Guess we are going back to the days when only nerds that knew how to flash better roms will be using Android.

Google is closing those gates as well. Pixel 10 drivers aren’t in the new AOSP build. Graphene has been updated to the Android 16 core, but as Google tightens the leash, it will be more difficult. Google’s plan to combine ChromeOS and Android into a MegaBloat will further make it so AOSP is useless.

Every time Google releases a new app for the core OS, they stop supporting the open-source flavor of it, which is why apps like the AOSP messaging app can’t do RCS. Eventually all that will be left of AOSP is a mostly useless husk.

Google’s intended use case for AOSP going forward is for vendors to be able to test pre-release things, primarily in an emulator environment.

Couple that with things like Samsung’s Qualcomm phones can’t be bootloader unlocked, and less and less phones in general can be bootloader unlocked, it is going to be an uphill battle for alt OSes.

Hopefully, this will drive enough dev time towards getting a proper Linux-based mobile device in the works, but even that will be problematic as most modems/chips available for that kind of project are inferior, slow, do not support all the bands/modes of modern carrier networks, and even after all of that, the carrier can still reject to certify the device for the network.

It isn’t hopeless, but everyone is going to have to get creative and driven if we have any intention of retaining free and open mobile devices.