This will become increasingly important as Google has boiled the frog too fast while trying to force its new store policies + banning sideloading; however, all of the pieces are now in place for them to try again in a year or 2, which history shows us they will. It’s certainly time to start toying with Linux phones if you haven’t already. This year I picked up an Xperia 10 to flash Sailfish OS on—which has rough edges (many of the hardware issues should be fixed in the next release), but Android App support bridges some of the gaps in application support.
I agree with the ethos but "banning installing" wouldn't have been correct here.
There should be terminology for installing from the source of your choice which doesn't carry the marginal or sinister connotations of "sideloading" though.
"Freeloading" would have been a good one but... yeah
If we're being pedantic, the user still has to perform the final action before the install begins. I think it' more "Google has to allow you to install apps on your phone"
My first encounter with "sideloading" I think was loading up a MP3 player with music, for some reason that was called "sideloading" by some people. In that case, "sideloading" was just transferring basically, nothing about installing.
But once Android appeared, and there was one Google-approved way of installing applications (Google Store) and one way of installing directly from .apk after enabling "Unknown Sources", then the word started to be used for the second approach.
I don't remember if it was Google who started using "sideloading" or the community itself, but regardless, "installing" would be a more understandable word for anyone to use for the processing of installing an application on your phone, as (what I recall to be) the original meaning was just transferring.
> My first encounter with "sideloading" I think was loading up a MP3 player with music, for some reason that was called "sideloading" by some people. In that case, "sideloading" was just transferring basically, nothing about installing.
Probably influenced by the original iPod, which really wanted you to sync your iPod with your iTunes library (conveniently directing you to purchase all of your music from Apple's platform). "Sideloading" referred to the few extra steps to get your computer to simply expose the iPod as a removable storage device and drag-and-drop your mp3s over that way.
It wouldn't have made sense in the context of other mp3 players, because for many of the ones I remember (like my Creative Zen Touch), that was the only way to add the mp3s. I don't think Creative even supplied a front-end media manager...or if they did, I never bothered installing it.
Steve Jobs himself said in his famous “Thoughts on Music” letter that was posted on the Apple home page that less than 10% of users music on iPods were bought from iTunes.
> Probably influenced by the original iPod, which really wanted you to sync your iPod with your iTunes library (conveniently directing you to purchase all of your music from Apple's platform).
iTunes (the software) came out before the iTunes (the music store) and iPods and Apple actually marketed the iMacs as “rip mix burn”.
Even before the iTunes store appeared, I always hated the over-complicated import/sync pattern.
1. "Import" your files into iTunes "library"
2. "Sync" that library with a device
My computer already has a filesystem. Why do I need to involve some application's "library"? I hate applications that insist on grafting its own "library" container on top of my already-working filesystem. My OS already allows me to copy files. Why do I need to rely on that application to copy files? Just expose the thing as a mass storage device and let me use my OS!
Because with iTunes, I could and did have regular playlists and smart playlists using conditions like ratings, last played, play count, number of times skipped (so that it would automatically be removed from a playlist if I continued to skip a song on my iPod or computer), genre, year released, etc.
You couldn’t have that metadata with just file syncing. Later when iTunes was introduced, it had to support DRM.
Later it also had podcast syncing.
I used iTunes to burn CDs before I had an iPod.
And don’t forget that Jobs being able to negotiate users being able to buy music on iTunes with DRM [1] and letting users burn them to a DRM free CD was so revolutionary that even Bill Gates was impressed.
[1] later Jobs argued in the same “Thoughts on Music” letter that instead of Apple licensing its DRM the record label should license DRM free music to everyone since most music was already sold as DRM free CDs and then everyone’s music could work anywhere. Only one record label took them up on the offer from day one. It wasn’t until 2009 that all of the record labels agreed.
Yeah, people in my circles and also people on the internet would refer to it as "sideloading" even though none of us were using iPods (I think this was all before the iPod actually, but my memory is a bit hazy), just copy-paste the files with explorer.exe over to the built-in MP3 player storage, people calling it "sideloading".
It's bypassing the usual channel for app installations, so the term is technically fitting and the loaded meaning is also appropriate since it's mostly used by nerds (maybe too strong a word) and bad actors.
There are legitimate uses of sideloading for regular users, for example if you have solar panels that work with a Huawei app, they can't put it on the Play store because of US sanctions. But that's not Google's fault, and that does mean the app is more risky since it's not monitored by Google.
(I'm not saying sideloading is otherwise illegitimate, it's an important feature but it's not something I'd normally recommend to a non-technical user that already chose to use a phone with Google's system.)
> that does mean the app is more risky since it's not monitored by Google.
Why is Google the arbitrator of risk here ?
As a user I'm capable of assessing the risk directly or indirectly by delegating that responsibility to another store or another program a.k.a anti-virus programs, its my choice in the end.
I want Google to build software like Windows Defender and allow others to build similar software. I want the ability to chose my security provider or not have one. I don't want Google to play nanny.
Because they do the monitoring and take some responsibility? I'm just comparing "install from the Play store" with "install some apk from wherever". If you bring additional context/knowledge of course it makes a difference.
Risk and responsibility are different. Monitoring, responsibility, those are just silly words with semantic games since Google's store is full of malware while F-Droid is not. Google's store is the risky one, and the words on their compliance statements are irrelevant to that fact.
I don't feel like I'm the one playing semantic games here, I'm just arguing that the term "sideloading" is a useful distinction vs "installing through the main channel" (whatever that is: could be the Play store, or F-Droid, or Huawei App Gallery).
Google's store has malware, but the point is there would be even more if Google was not monitoring the apps there. The store is less risky than getting apks from the wild web, TikTok, etc.
Sure F-Droid is safer (as you would expect from a curated store of a few thousand open source apps compared to a store with literally millions of apps). But I wouldn't call that sideloading either when it's your regular channel to get apps.
Just because its the channel that google would prefer you use doesn't mean its "the usual channel". What counts as "usual" is user specific. I don't even have google play installed on my Android phone.
Sure, but if we want to chip away at that majority, we need to encourage them to think of using the play store as a choice they have. Implicitly assuming that "install" means "install from the play store" is counterproductive.
I'm curious what's your actual opinion in absence of hard data. If your grandma tells you a website gives her instructions for sideloading Candy Crush, you'd say yeah fine or advise her to go through the Play store?
Exactly. Let's invent a word for "installing from play store". Playstoring?
So we can rewrite the story to something like: Google wants to prohibit app installation on Android phones. The only way to get an app would be through playstoring.
I can install on my Fedora laptop through dnf. I've never felt like I needed a new word to describe downloading and running an AppImage. Why would phones be different?
`adb sideload` existed as a command for installing an apk from your PC on to your phone. Sideloading was not meant to refer to installing an apk on the phone from the phone.
That actually sounds like a good idea, the situation is similar with an official channel of "trusted" software for which the distributor takes some responsibility, versus whatever file you downloaded yourself. It's certainly more risky on a Debian system to install a .deb from some random website, or an AppImage, compared to a .deb from the official repositories. I guess it's the same for Fedora.
The whole selling point of Android up until now was that it allowed you to install any app you want.
The point of the above comment is that Google intentionally introduced the word "sideload" to make "installing an app on your own device which Google did not curate" sound more risky and sinister than it is, and I'm inclined to agree.
I "make" coffee on my keurig. If Keurig decides that making any single-serve coffe pods that aren't owned by the Keurig brand is now called "off-brewing," I'd dismiss it as ridiculous and continue calling it "making coffee."
We should use the language that makes sense, not the language that happens be good PR for google.
>The whole selling point of Android up until now was that it allowed you to install any app you want.
Could've fooled me. Maybe it was a thing a decade ago when android just launched, but none of the marketing pages for vaguely recent phones has that as a selling point. At best it's a meme that android proponents repeat on hn or reddit.
We're not talking about phones, we're talking about an operating system. If those companies could port IOS to their phone, they probably would. Since the OS will be mostly the same across devices, it makes sense to market a phone based on hardware differences -- like having a higher quality camera.
I've never met or talked to an android user that truly believes android is better technology or a better user experience. They all use it because of flexibility.
You've changed the subject. We were discussing whether one ought to use Google's term for it, or the term that's been used to describe this action since (I assume) the beginning of personal computing. Not whether Google is legally allowed to make the change.
My reason for bringing up the "selling point" was to bring attention to the language -- "You can install any app you want" has always been the common refrain when I see friends get into a debate about IOS vs Android. People are already using the term because it makes the most sense.
Calling something a right is an assertion about morality; it implies that a law to the contrary would be a violation of that right.
I do not believe an an OS vendor with an app store has a right to limit alternate distribution channels or that a government does something wrong by restricting such practices as unfair competition.
"I do not believe an an OS vendor with an app store has a right to limit alternate distribution channels or that a government does something wrong by restricting such practices as unfair competition."
but its not illegal and wrong tho???? if this is probihited then xbox,playstation,nintendo,ios etc would be fined already
unironically android is still more "open" than all of its competitor even after all of this
It might be illegal in the EU under the DMA. As I understand it, litigation involving Apple's equivalent is in progress, and the outcome may not be known for years.
Wrong in this context is an assertion about morality. I do think it's wrong in the context of consumer products for a vendor to attempt to override the wishes of the owner of the product outside of a few narrow exceptions. I would absolutely apply that to iOS, and I think the DMA didn't go far enough; Apple should have no ability to enforce notarization or charge fees to app developers if the device owner chooses otherwise.
I feel less strongly about game consoles because they're not as important as smartphones; they don't touch most aspects of life in modern society, and there are viable alternatives for their primary function, such as gaming on PCs. I don't like their business model and I don't own one.
all of big tech doing it for 20+ years and suddenly google isnt allowed to do "industry standard", like what we talking about here????
I know its bad for pro-sumer which is minority but consumer would get more protection which is majority so I dismiss HN audience because they are biases vs normal people
They all should be? I've never understood why gamers just accept constant blatant anti-competitive practices, going so far as to act as if "exclusives" via DRM are a good thing rather than monopolistic product tying. e.g. it's been demonstrated that a Steam Deck is technically capable of running Switch games better than a Switch, and yet you are forced to buy a Switch in order to buy the games.
It's no longer 30 years ago when hardware was unique and quirky and programs were written in assembly specifically for the hardware. It's all the same commodity parts along with what is supposed to be illegal business practices. In a reasonable world, something like Ryujinx would be just as front-and-center as Proton as part of Valve's product features, and courts would fine companies for trying to stop their software from working on other platforms.
Antitrust law exists exactly to prevent companies from making their own ecosystem/walled garden that competitors cannot sell into. Product tying (forcing you to buy product B in order to buy product A) falls under that umbrella. Game console are not magical in this regard.
Lots of us have a problem with all of those things, and would like the government to enforce the law. I've never bought an Apple product, and the last game console I owned was a PS2 when I was a child.
I do not get this use of the word "reality"? The reality is Ted Bundy's currently-at-large successor has the ability to shoot me with a gun. And that fact is about as relevant as what you said.
What you're doing here is resigning from a game just because of the fact there is a game, and then being condescending to other people for trying to win the game instead, as if what you're doing is something superior. This would already be very odd behaviour if this were only Monopoly or Risk, but is downright dangerous propaganda when the game is capitalism and the future of free computing is at stake.
I'm not too familiar with macOS... How normal/expected is it now to install through the App Store? As mentioned in another comment, for a Linux distribution like Debian there are highly trusted official repositories, and I think using "sideloading" for other sources would make some sense.
On macos I assume most apps are installed outside of the Store, straight from the developper's site. Which would make the Store a "sideloading" channel by that token ?
On Linux you have the default package sources, but for instance adding third party sources will still integrate the same with the system, I also never heard someone call installing Go or Java "side loading", though you're getting an installer from the site you need to run on your own. Same way for building from source.
IMHO "sideloading" would not apply to any system open enough, where adding stuff from multiple sources is expected from the start.
> Which would make the Store a "sideloading" channel by that token ?
I don't think so, it's still an official channel offered by the OS maker.
> adding third party sources will still integrate the same with the system
but obviously with a higher risk of breakage since it was not tested while the official release was cooking (at least for Debian the official set of packages in stable is expected to have virtually no conflict issues, but as soon as you add third-party sources all bets are off).
> I also never heard someone call installing Go or Java "side loading"
neither have I, but I can imagine that in some contexts it could be a useful term. Like "did you sideload Go?" (implicitly asking if you got the third-party release vs installing from the official distribution repository). I'm not saying people say that, but that the term might also make sense in the Linux world.
> IMHO "sideloading" would not apply to any system open enough, where adding stuff from multiple sources is expected from the start.
Yeah if there's no sense of "main" channels that are more trusted or more stable the term doesn't make sense.
Doesn't feel like any conspiracy.. Isn't sideloading installing through adb instead of from the system itself? (by clicking on an APK or using an app Store like Xiaomi/Googled/Huawei/Fdroid)
No, on android, it always meant installing an APK directly, without a store-app. You can use ADB, but you also can just download the APK on your device and install it locally with your browser or filemanager.
sure, google is trying to cash in. not saying theyre nice people. but the handwringing over semantics and suggesting Google has a master plan to abuse vocabular just sounds ridiculous
What exactly is ridiculous to the idea, that maybe there was a google meeting where the name was debated and the pro and cons of different names evaluated from their buisness perspective?
I just bought a second Fairphone 4 just to play a bit with pmOS. I'm really surprised by the state it is. It's not fully usable as a daily driver yet, but with some work it can get there. Waydroid works also pretty good. Of course, the major problem are banking apps and similar. I hope that some progress can be done in this direction. And, who needs working audio, if you can have python and git in your phone!? :P
I made a partition for Nix on mine so I have all the tools I need while not relying on Jolla to package things (the installable package list is quite barren). My audio works from the speakers, but the patches to make the headphone jack (something you Fairphone users no longer know of :P) work won’t come til the next release. For banks, I just use cash or log into the website on my laptop if required—while I will refuse goods/services that require an apps to the fullest extent possible (couldn’t get around TicketMaster which was a real blood-boiler beyond just the “phone required” aspect).
Yes, I think that just trying to use services that don't require special mobile apps can get you a long way. It is sometimes difficult, but now I'm beginning to move more in this direction :)
It’s the same as unGoogling your life where you can slowly start moving off one service at a time & make sure new ones you use are open or at least otherwise ethical.
Did you test apps that need sensors and notifications? If I want to run an OpenStreetmaps apk (there's no good way to run OMS on Linux natively), do I get GPS and compass heading? Do I get turn-by-turn navigation? Even if the app is in the background?
But for the reason an antiquated os like postmarketos are suggested is that the project is being opportunistic thinking this is a chance they can be relevant. Additionally, the population of HN has more sentimental view on these legacy operating systems and view it as a chance to go back to the past and use software they are familiar with.
I really wanted to like Graphene OS but I ended up bouncing off it due to a few major pain points that badly effected battery life.
- Using the default 5g setting resulted in far worse battery life than stock, telling people to choose 4g isn't a solution. They desperately need something like the adaptive connectivity service.
- Using Homeassistant's GPS tracking feature just destroyed the battery life, even switching to 4g didn't solve this issue. Changing all the GPS settings didn't help either.
- The obnoxious green GPS active icon makes the notification bar useless if using a GPS tracking app (or even gps navigation). The request for a whitelist was either ignored or rejected, the teams communication can come off a bit rough.
No normal user is going to be happy with Grapheneos. From what I've seen postmarketos is much more user friendly.
I don't know what to say about your battery life issue, other than that I don't have any such problems.
What's obnoxious about the green GPS icon? How does it make the notification bar useless? It is on all the time while I'm using Google Maps, it's small and not in the way and is a good reminder if I have accidentally left Google Maps open in the background. What's the problem?
I don't recognise the 5g battery life issues personally. I do 100% agree the GPS thing is such a bad decision. It just becomes noise that no one pays attention to anymore.
I ended up using my public ip address in combination with a list of known ips for home and work and such, and building my HA automations around that. I wanted to do it with wifi SSID's, but that also requires the location permission and triggers the indicator (which is understandable, just wish I could still read SSID's with location services disabled entirely) (or, just let me disable the gps antenna and leave everything else).
> I do 100% agree the GPS thing is such a bad decision. It just becomes noise that no one pays attention to anymore.
It's not noise for me, I only ever have GPS on for Google Maps, and I like the indicator because its absence reassures me that nothing is using GPS in the background.
I also want to have audible notification or, even better, a loud siren when GPS, or WiFi are activated without my direct action. Sadly, SafeDot doesn't work properly on Graphene.
It certainly could be something else other than 5g but it's one of the first things that gets thrown around when battery drain is mentioned and the mobile internet was the main user of power on the phone.
> No normal user is going to be happy with Grapheneos.
I am a normal user, extremely happy with GrapheneOS. I just don't use HomeAssistant, which seems to have been your dealbreaker in this case.
I genuinely don't see a difference between Stock Android and GrapheneOS, except that I get more updates and I have more privacy controls (like scopes, but honestly I haven't had a need to use them yet).
You are very fortunate for not hitting any edge cases, but sorry anyone commenting here typically isn't anywhere near to what you could call a "normal user". I ran into quite few minor issues with the enhanced security settings, my partner would never been able to figure out the solution to that issue and I consider them a normal user.
Not to mention the 5g battery drain is a hard show stopper, not just Homeassistant issues. I even experimented with different apps like owntracks but same problem with GPS.
I found a solution to the GPS icon but it requires an ADB command so not a great fix.
There is no reason to hard fork, as long as Google contributes to AOSP without breaking it.
Regulators in the US decided that Android did not have to be split from Google, but they could theoretically decide that Google is not allowed to break AOSP to gain a competitive advantage. Not that it would matter: TooBigTech is too powerful to care about regulations anyway.
I actually wonder: if Google stopped pushing to AOSP and "the community" had to fork... the whole Android SDK/NDK is not open source, so I wonder if AOSP could survive at all without Google, even though it is open source.
I think if Google would stop pushing AOSP, there's a very high risk for Google that a consortium of manufacturers would continue themselves as they need it and they would lose control.
I think that is unlikely reality because from manufacturers perspective they don't get AOSP from the public. They get it from their chip provider like Qualcomm who gets private releases from Google. Everything is already set up such that people aren't using the public version, so the more likely reality is that the public version goes away, and google partners keep doing what they are doing. Maybe things are different on the Chinese side of things. So if it were to be created, it would be over there.
Would they, though? Like Huawei forked for a while, and then they made their proprietary HarmonyOS.
For a while I thought it was a missed opportunity to compete on a hard fork, but then I realised that Huawei probably cannot fork the Android SDK/NDK because it's not open source.
One of the other appeals of the Android ecosystem was a large selection of hardware for user-specific needs. GrapheneOS only supports Google Pixel phones which do not compare to the sorts of hardware postmarketOS or other Linux OS support.
At least in regards to the security model, it is decades out of date. For example any app can listen to your microphone and spy on you at anytime. Programs can act as ransomeware or destroy all of your files. Stealers can steal your login credentials and access tokens for all your sites including banking ones.
Linux doesn't solely rely on the Unix security model. Linux security is mostly based on trust, the trust of the distribution and its maintainers. But if you want to run random, untrusted apps you'll want a different model. Linux is slowly addressing that need w/ a variety of different approaches which could be picked up and used for a mobile OS.
Well, isn't the idea that you use apps compiled from source by distro maintainers, which are separate from the upstream maintainers ?
Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.
Not to mention the security model preventing many useful things from working properly (try to get a SFTP working on an Android system so that you can copy out photos taken by the phones camera.
> Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.
You're comparing a security model to... apps? I don't see how that makes sense.
Apps you install on Linux can do more than apps you install on Android, period. That's part of the security model.
Of course I like that I am an admin on my computer, but I don't need that on my phone. And one can enable root on Android and still keep the apps sandboxed...
>isn't the idea that you use apps compiled from source by distro maintainers
That might work if the main danger was upstream maintainers with bad intentions. But the main danger is security holes that no upstream or distro maintainer knows about, which allow attacks by parties that are not open-source maintainers.
Big picture is that GrapheneOS is much, much more secure than PostmarketOS.
I think the important distinction is _everything_ should be considered untrusted because even trustworthy software can become malicious. For example, the XZ Utils backdoor[0].
On Android, everything I run is subject to the permission model and sandboxed. That is not the case on Linux.
Could you be more specific on how to circumvent the android permission model + sandbox? So far I have only thought of two ways an XZ-like backdoor could circumvent that:
1. By being baked into the OS itself, which is unavoidable since the OS is the thing providing the sandboxing + security model. It still massively reduces the attack surface.
2. By being run through the android debug bridge, which is far from normal and something users have to explicitly enable. Leaving you the option to shoot yourself in the foot in an opt-in manner 99.9% of users will never touch isn't the same as Linux where foot-shooting is the default.
The defining aspect of the XZ backdoor was that it was baked into the OS itself, being linked into memory space by about half of the system and activated by being packaged in a specific way in a specific distribution. If you wanted to ignore 1), you would have to choose a different example.
If you want to confine yourself in a sandbox, feel free to do it. The past decades have demonstrated that it's only necessary for some specific threat models.
You can configure your flatpak app so that it will have permission to read microphone in the background or have full access to the disk. Many flatpaks of real apps request dangerous permissions that users have been conditioned to ignore. For example Blender is such an app which has full disk access and background microphone access, and I'm sure many people have installed that. This is unlike Android where these are locked down for every app.
...and if you want an Android app to actually be able to do something useful, you give it root permissions and completely bypass the permission model.
The world isn't black and white. Most reasons why Android apps are being so heavily locked down don't apply to Blender. As a user, I'm not interested in Android-bis - if I were, I would just use Android after all. Nevertheless, things like Flatpak give me, the user, the power over application's permissions and I can take them away (or give more) in a few taps at will. The defaults being tuned for different use cases and threat models are not "being decades out of date", especially when you could already use the existing tooling to replicate other models - regardless of whether you happen to like these defaults or whether they fit your specific use case.
This is not possible on a device following the Android security model. Permissioned features should always be implemented using proper security mechanisms like permissions.
>don't apply to Blender
You say that until the SuperRetopologyTools5000.py addon you try out infects your system.
>Flatpak give me, the user, the power over application's permission
Most people are not going to bother with this. It's important for the defaults to be secure. People shouldn't have to opt in to a secure experience, and doing so shouldn't break the program.
> This is not possible on a device following the Android security model.
Yes, that's the user experience on such devices. "This is not possible on a device following the Android security model, either bypass it or use another device".
I had an Xperia for awhile. I liked it while it was new, but after a year the back started peeling off.
Pretty lousy for a phone that was supposed to be waterproof. At that point I realized that the Japanese change out their phones every 6-12 months, thus Sony didn't realize that the market demands much longer reliability in a smartphone.
They do a good job contributing upstream to the kernel & are one of the few phones out there that still allow users to unlock the bootloader & they support headphone jacks + microSD cards.
I think this stuff is super important, simply because there is a ton of stuff we can't do using our phones today.
Think mesh networking, resilient ad-hoc application clustering, non-Internet P2P, like Freifunk but everywhere. We shouldn't have to depend on Google or any of the big tech companies for anything except the hardware.
That would offer much more freedom. There are also contexts where this kind of thing could also enable life-saving applications. And unlike todays Internet where a database query in Cloudflare or a DNS bug in es-east-1 can disrupt half the services we use, this kind of technology really could withstand major attacks on infrastructure hubs, like the Internet was originally designed to do.
Twenty years ago, if you told me that by today we'd have smart phones with eight or more cores, each outperforming an average desktop computer of the time, with capacitive OLED touch screens, on a cellular network with hundreds of megabits of bandwidth, I'd find it believable, because that's where technology was headed at the time.
If you said that they'd effectively all be running either a port of OS X or a Linux distribution with a non-GNU but open source userspace, I'd consider that a somewhat unexpected success of open-source software. I would not at all expect that it would be as locked down as video game console.
The more time passes, the less I use my phone for, and the more likely I am to whip out my laptop to accomplish something, like it's 2005.
The open source components in your android phone are suffering from what FSF called "tivoization" a few decades ago. They can't reasonably be replaced without breaking security measures, a pretty high barrier for most users, even sometimes for advanced users. It removes the biggest benefits of being open source.
>Think mesh networking, resilient ad-hoc application clustering, non-Internet P2P, like Freifunk but everywhere.
(if dumbed down) What's are the gaps in features and functionality between what you're describing and what might be achievable today (given enough software glue) with an SDR transceiver and something like Reticulum [1] on an Android?
SDR + something like Reticulum or Yggdrasil would definitely provide the infra or network fabric for the kind of thing I'm thinking of.
However, a normal Android, e.g. a Pixel 7, can't to my knowledge be turned into a web server or a podman host for containers. (I know of people hosting websites on old Androids that are flashed or hacked).
Given phones already have a WiFi/WLAN radio chip, it's a shame to need extra kit for connectivity.
It's something that's been on my mind a lot recently and so you provoked me into writing down a series of scenarios in story format that illustrates what SHOULD be possible using current hardware, were it not, as dlcarrier says, locked down like a games console.
I installed PmOS on my old Xiaomi redmi note 9 with KDE Plasma Desktop. It works remarkably well, with the exception of sound. I am using it as a full Linux PC when I am on the go with my large power bank and a full sized folding keyboard/track pad.
For my use case it's beyond great, albeit the small screen and the aarch architecture I can develop small projects as if I was on my PC.
My current phone OP13r doesn't is supported yet by PmOS, when someone does it Im gonna try to install it on one of the slots.
Lineageos maintains a list and you can filter for devices with official bootloader unlock https://wiki.lineageos.org/devices/. Buy only these devices to signal to these companies that this matters.
Noteably OnePlus 13 and Pixel 9a, both 2025 phones, can be unlocked.
If someone want something also quite recent and cheaper in this supported list there is also motorola edge+ (2023) with good specs. I got myself refurbished with perfect condition for just 240usd.
I wonder if there's some sort of GSM hotspot device where it connects to 4G/5G networks, but creates a small localised 2G/3G cell for older phones. Kind of like how we have mobile hotspot devices, but instead of (or addition to) creating a WiF hotspot, they provide 2G/3G...
If anyone wants a table for the testing devices (which are arguably still quite stable!), here's a table I put together by scraping the site a few months ago:
It's a shame phones didn't get anything similar to BIOS back in a day.
Imagine if every laptop manufacturer had not a couple of incompatible sensors, but a whole unique boot system only allowing you to boot a crippled version of Windows ME.
Yeah, the requirement to build and provide device trees for most mobile devices is the huge issue. For all of the garbage we have gotten from buggy ass ACPI tables on assorted PC’s, it’s absolutely true that it solved a lot of headaches with hardware discovery/enumeration.
It’s really too bad that ARM had adopted ACPI as part of their SystemReady certification. It does work, and not reinventing the wheel is always a wise where feasible, but I think we could absolutely push something better.
I've never seen UEFI in any mainstream Android device.
The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.
That means that at least the initial bringup for a second-stage bootloader is incredibly easy, less than 40 lines of assembler code [1]. And when you write a tiny operating system, as long as you're content with that basic foundation of 640x480 and text output, it will run on any x86 compatible PC or server.
On anything ARM, that's outright impossible to do and that is a large part of the problem. ARM is power efficient, but it comes at a serious cost. The low level bringup will be handled by the board's ROM, similar to PC BIOS/EFI, but after control is passed to the OS it gets different - all the OS gets is the devicetree stating "here's the memory addresses and interfaces of the hardware in the system", but you still need to write drivers for each and every individual thing from the bottom up, there is no framework for even most basic hardware interactions.
I have many x86 devices that don't provide a CSM, so no, it's untrue that it will run on any arbitrary x86 device. You can do something similar running entirely inside the UEFI boot services environment - and that'll work just as well on any of the large number of UEFI-based ARM phones.
09h is keyboard interrupt, the utter basic interface [1] that only gives you scancodes and that's it, 16h is the extended interface [2] that you need to deal with if you want to read/set shift and other special keys [3].
google/android/apple/microsft are fighting for there lives, as there is no reason for there continued existance
all the important types of comunications can be hard coded into chips and operate free of any external OS, everything else is two way media, 95% of which can be handled on local networks
what big tech is trying to build is something alien to human needs, false promises and enticements, faked up ideals bases on faked up images and outright lies served by monsterous AI data farms that look more and more like the set of "the matrix"
the issue with that, is that it is essentialy empty and boring, demanding that the viewer suspends ANY judgement or discernment and further defend this completly impossible and artificial media creation as real.
litteral zombies.
In a competitive market, companies are fighting for their lives. The companies you listed are fighting to put up barriers to competition and are succeeding to a great measure.
It's called installing. Language matters and I see no reason to concede this point in Google's favour.
There should be terminology for installing from the source of your choice which doesn't carry the marginal or sinister connotations of "sideloading" though.
"Freeloading" would have been a good one but... yeah
(not really final, Google can uninstall your apps anytime if they are deemed undesirable)
(interestingly the keyboard app is not among these, so my sister has uninstalled it by mistake once)
'installing from beyond the walled garden' would be a nice fit here imo
"Installing arbitrary packages"
vs
"Installing google-approved packages"
it would
and it would show exactly why it is absurd
But once Android appeared, and there was one Google-approved way of installing applications (Google Store) and one way of installing directly from .apk after enabling "Unknown Sources", then the word started to be used for the second approach.
I don't remember if it was Google who started using "sideloading" or the community itself, but regardless, "installing" would be a more understandable word for anyone to use for the processing of installing an application on your phone, as (what I recall to be) the original meaning was just transferring.
Probably influenced by the original iPod, which really wanted you to sync your iPod with your iTunes library (conveniently directing you to purchase all of your music from Apple's platform). "Sideloading" referred to the few extra steps to get your computer to simply expose the iPod as a removable storage device and drag-and-drop your mp3s over that way.
It wouldn't have made sense in the context of other mp3 players, because for many of the ones I remember (like my Creative Zen Touch), that was the only way to add the mp3s. I don't think Creative even supplied a front-end media manager...or if they did, I never bothered installing it.
Steve Jobs himself said in his famous “Thoughts on Music” letter that was posted on the Apple home page that less than 10% of users music on iPods were bought from iTunes.
> Probably influenced by the original iPod, which really wanted you to sync your iPod with your iTunes library (conveniently directing you to purchase all of your music from Apple's platform).
iTunes (the software) came out before the iTunes (the music store) and iPods and Apple actually marketed the iMacs as “rip mix burn”.
1. "Import" your files into iTunes "library"
2. "Sync" that library with a device
My computer already has a filesystem. Why do I need to involve some application's "library"? I hate applications that insist on grafting its own "library" container on top of my already-working filesystem. My OS already allows me to copy files. Why do I need to rely on that application to copy files? Just expose the thing as a mass storage device and let me use my OS!
You couldn’t have that metadata with just file syncing. Later when iTunes was introduced, it had to support DRM.
Later it also had podcast syncing.
I used iTunes to burn CDs before I had an iPod.
And don’t forget that Jobs being able to negotiate users being able to buy music on iTunes with DRM [1] and letting users burn them to a DRM free CD was so revolutionary that even Bill Gates was impressed.
https://9to5mac.com/2021/07/09/unearthed-email-shows-bill-ga...
[1] later Jobs argued in the same “Thoughts on Music” letter that instead of Apple licensing its DRM the record label should license DRM free music to everyone since most music was already sold as DRM free CDs and then everyone’s music could work anywhere. Only one record label took them up on the offer from day one. It wasn’t until 2009 that all of the record labels agreed.
Let's just call it alternate install.
There are legitimate uses of sideloading for regular users, for example if you have solar panels that work with a Huawei app, they can't put it on the Play store because of US sanctions. But that's not Google's fault, and that does mean the app is more risky since it's not monitored by Google.
(I'm not saying sideloading is otherwise illegitimate, it's an important feature but it's not something I'd normally recommend to a non-technical user that already chose to use a phone with Google's system.)
Why is Google the arbitrator of risk here ?
As a user I'm capable of assessing the risk directly or indirectly by delegating that responsibility to another store or another program a.k.a anti-virus programs, its my choice in the end.
I want Google to build software like Windows Defender and allow others to build similar software. I want the ability to chose my security provider or not have one. I don't want Google to play nanny.
Because they do the monitoring and take some responsibility? I'm just comparing "install from the Play store" with "install some apk from wherever". If you bring additional context/knowledge of course it makes a difference.
Google's store has malware, but the point is there would be even more if Google was not monitoring the apps there. The store is less risky than getting apks from the wild web, TikTok, etc.
Sure F-Droid is safer (as you would expect from a curated store of a few thousand open source apps compared to a store with literally millions of apps). But I wouldn't call that sideloading either when it's your regular channel to get apps.
This implies the play store isn't hosting tonnes of malware right now
It gets tricky with alternative stores like F-Droid. I guess if you use F-Droid as a trusted source then it shouldn't be called sideloading.
it's google's monopolized install that needs to be called by a long name
So we can rewrite the story to something like: Google wants to prohibit app installation on Android phones. The only way to get an app would be through playstoring.
Installing an APK directly through your phone is in fact NOT sideloading.
google has control on their android ecosystem behave, same reason why its not allowed in playstation or xbox or ios
The point of the above comment is that Google intentionally introduced the word "sideload" to make "installing an app on your own device which Google did not curate" sound more risky and sinister than it is, and I'm inclined to agree.
I "make" coffee on my keurig. If Keurig decides that making any single-serve coffe pods that aren't owned by the Keurig brand is now called "off-brewing," I'd dismiss it as ridiculous and continue calling it "making coffee."
We should use the language that makes sense, not the language that happens be good PR for google.
Could've fooled me. Maybe it was a thing a decade ago when android just launched, but none of the marketing pages for vaguely recent phones has that as a selling point. At best it's a meme that android proponents repeat on hn or reddit.
I've never met or talked to an android user that truly believes android is better technology or a better user experience. They all use it because of flexibility.
we can debate whether this is bad thing or good thing, it would have no ends
what matters is reality, the reality is google have the right to change it.
My reason for bringing up the "selling point" was to bring attention to the language -- "You can install any app you want" has always been the common refrain when I see friends get into a debate about IOS vs Android. People are already using the term because it makes the most sense.
the asnwer is not anymore
sideload is illegal
I do not believe an an OS vendor with an app store has a right to limit alternate distribution channels or that a government does something wrong by restricting such practices as unfair competition.
but its not illegal and wrong tho???? if this is probihited then xbox,playstation,nintendo,ios etc would be fined already
unironically android is still more "open" than all of its competitor even after all of this
Wrong in this context is an assertion about morality. I do think it's wrong in the context of consumer products for a vendor to attempt to override the wishes of the owner of the product outside of a few narrow exceptions. I would absolutely apply that to iOS, and I think the DMA didn't go far enough; Apple should have no ability to enforce notarization or charge fees to app developers if the device owner chooses otherwise.
I feel less strongly about game consoles because they're not as important as smartphones; they don't touch most aspects of life in modern society, and there are viable alternatives for their primary function, such as gaming on PCs. I don't like their business model and I don't own one.
all of big tech doing it for 20+ years and suddenly google isnt allowed to do "industry standard", like what we talking about here????
I know its bad for pro-sumer which is minority but consumer would get more protection which is majority so I dismiss HN audience because they are biases vs normal people
It's no longer 30 years ago when hardware was unique and quirky and programs were written in assembly specifically for the hardware. It's all the same commodity parts along with what is supposed to be illegal business practices. In a reasonable world, something like Ryujinx would be just as front-and-center as Proton as part of Valve's product features, and courts would fine companies for trying to stop their software from working on other platforms.
I know, I know everything can be a "PC" if you look close enough but hear me
people can create their own ecosystem of walled garden whenever they want
game console has been doing it for 20+ years and they are fine, apple has doing it for 10+ years and they are fine
Google wants doing it???? they are fine to do that. if you have problem then you are hypocrite
What you're doing here is resigning from a game just because of the fact there is a game, and then being condescending to other people for trying to win the game instead, as if what you're doing is something superior. This would already be very odd behaviour if this were only Monopoly or Risk, but is downright dangerous propaganda when the game is capitalism and the future of free computing is at stake.
that is what AOSP are, android remain "free"
the ecosystem around android??? remain google rights and rightfully so since google fund and develop most of it
same like apple does, microsoft does, nintendo does. nothing wrong againts that
On Linux you have the default package sources, but for instance adding third party sources will still integrate the same with the system, I also never heard someone call installing Go or Java "side loading", though you're getting an installer from the site you need to run on your own. Same way for building from source.
IMHO "sideloading" would not apply to any system open enough, where adding stuff from multiple sources is expected from the start.
I don't think so, it's still an official channel offered by the OS maker.
> adding third party sources will still integrate the same with the system
but obviously with a higher risk of breakage since it was not tested while the official release was cooking (at least for Debian the official set of packages in stable is expected to have virtually no conflict issues, but as soon as you add third-party sources all bets are off).
> I also never heard someone call installing Go or Java "side loading"
neither have I, but I can imagine that in some contexts it could be a useful term. Like "did you sideload Go?" (implicitly asking if you got the third-party release vs installing from the official distribution repository). I'm not saying people say that, but that the term might also make sense in the Linux world.
> IMHO "sideloading" would not apply to any system open enough, where adding stuff from multiple sources is expected from the start.
Yeah if there's no sense of "main" channels that are more trusted or more stable the term doesn't make sense.
"Side" being.. from your computer
You also know, what is commonly used for making profit? PR.
And they are all about changing the meaning of words, to achieve a certain effect in people.
https://en.wikipedia.org/wiki/Torches_of_Freedom
What exactly is ridiculous to the idea, that maybe there was a google meeting where the name was debated and the pro and cons of different names evaluated from their buisness perspective?
Did you test apps that need sensors and notifications? If I want to run an OpenStreetmaps apk (there's no good way to run OMS on Linux natively), do I get GPS and compass heading? Do I get turn-by-turn navigation? Even if the app is in the background?
Unfortunately CoMaps doesn't seem to have desktop client builds at all yet.
But it's less full-featured than the mobile-only versions.
eOS is basically what you are looking for for most phones or GrapheneOS (pixel only)
https://grapheneos.org/
But for the reason an antiquated os like postmarketos are suggested is that the project is being opportunistic thinking this is a chance they can be relevant. Additionally, the population of HN has more sentimental view on these legacy operating systems and view it as a chance to go back to the past and use software they are familiar with.
- Using the default 5g setting resulted in far worse battery life than stock, telling people to choose 4g isn't a solution. They desperately need something like the adaptive connectivity service.
- Using Homeassistant's GPS tracking feature just destroyed the battery life, even switching to 4g didn't solve this issue. Changing all the GPS settings didn't help either.
- The obnoxious green GPS active icon makes the notification bar useless if using a GPS tracking app (or even gps navigation). The request for a whitelist was either ignored or rejected, the teams communication can come off a bit rough.
No normal user is going to be happy with Grapheneos. From what I've seen postmarketos is much more user friendly.
What's obnoxious about the green GPS icon? How does it make the notification bar useless? It is on all the time while I'm using Google Maps, it's small and not in the way and is a good reminder if I have accidentally left Google Maps open in the background. What's the problem?
I ended up using my public ip address in combination with a list of known ips for home and work and such, and building my HA automations around that. I wanted to do it with wifi SSID's, but that also requires the location permission and triggers the indicator (which is understandable, just wish I could still read SSID's with location services disabled entirely) (or, just let me disable the gps antenna and leave everything else).
It's not noise for me, I only ever have GPS on for Google Maps, and I like the indicator because its absence reassures me that nothing is using GPS in the background.
I am a normal user, extremely happy with GrapheneOS. I just don't use HomeAssistant, which seems to have been your dealbreaker in this case.
I genuinely don't see a difference between Stock Android and GrapheneOS, except that I get more updates and I have more privacy controls (like scopes, but honestly I haven't had a need to use them yet).
Not to mention the 5g battery drain is a hard show stopper, not just Homeassistant issues. I even experimented with different apps like owntracks but same problem with GPS.
I found a solution to the GPS icon but it requires an ADB command so not a great fix.
That's not a hard fork. They always rebase on top of AOSP when there's a new AOSP source release
Regulators in the US decided that Android did not have to be split from Google, but they could theoretically decide that Google is not allowed to break AOSP to gain a competitive advantage. Not that it would matter: TooBigTech is too powerful to care about regulations anyway.
If you don't rebase from AOSP, the apps won't run pretty quickly.
For a while I thought it was a missed opportunity to compete on a hard fork, but then I realised that Huawei probably cannot fork the Android SDK/NDK because it's not open source.
Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.
Not to mention the security model preventing many useful things from working properly (try to get a SFTP working on an Android system so that you can copy out photos taken by the phones camera.
You're comparing a security model to... apps? I don't see how that makes sense.
Apps you install on Linux can do more than apps you install on Android, period. That's part of the security model.
Of course I like that I am an admin on my computer, but I don't need that on my phone. And one can enable root on Android and still keep the apps sandboxed...
That might work if the main danger was upstream maintainers with bad intentions. But the main danger is security holes that no upstream or distro maintainer knows about, which allow attacks by parties that are not open-source maintainers.
Big picture is that GrapheneOS is much, much more secure than PostmarketOS.
I think the important distinction is _everything_ should be considered untrusted because even trustworthy software can become malicious. For example, the XZ Utils backdoor[0].
On Android, everything I run is subject to the permission model and sandboxed. That is not the case on Linux.
[0] https://en.wikipedia.org/wiki/XZ_Utils_backdoor
1. By being baked into the OS itself, which is unavoidable since the OS is the thing providing the sandboxing + security model. It still massively reduces the attack surface.
2. By being run through the android debug bridge, which is far from normal and something users have to explicitly enable. Leaving you the option to shoot yourself in the foot in an opt-in manner 99.9% of users will never touch isn't the same as Linux where foot-shooting is the default.
If you want to confine yourself in a sandbox, feel free to do it. The past decades have demonstrated that it's only necessary for some specific threat models.
I want to confine apps in a sandbox. Android has that, Linux... well not really. I mean "it's possible", but it's not integrated like in Android.
You can configure your flatpak app so that it will have permission to read microphone in the background or have full access to the disk. Many flatpaks of real apps request dangerous permissions that users have been conditioned to ignore. For example Blender is such an app which has full disk access and background microphone access, and I'm sure many people have installed that. This is unlike Android where these are locked down for every app.
The world isn't black and white. Most reasons why Android apps are being so heavily locked down don't apply to Blender. As a user, I'm not interested in Android-bis - if I were, I would just use Android after all. Nevertheless, things like Flatpak give me, the user, the power over application's permissions and I can take them away (or give more) in a few taps at will. The defaults being tuned for different use cases and threat models are not "being decades out of date", especially when you could already use the existing tooling to replicate other models - regardless of whether you happen to like these defaults or whether they fit your specific use case.
This is not possible on a device following the Android security model. Permissioned features should always be implemented using proper security mechanisms like permissions.
>don't apply to Blender
You say that until the SuperRetopologyTools5000.py addon you try out infects your system.
>Flatpak give me, the user, the power over application's permission
Most people are not going to bother with this. It's important for the defaults to be secure. People shouldn't have to opt in to a secure experience, and doing so shouldn't break the program.
Yes, that's the user experience on such devices. "This is not possible on a device following the Android security model, either bypass it or use another device".
I had an Xperia for awhile. I liked it while it was new, but after a year the back started peeling off.
Pretty lousy for a phone that was supposed to be waterproof. At that point I realized that the Japanese change out their phones every 6-12 months, thus Sony didn't realize that the market demands much longer reliability in a smartphone.
Think mesh networking, resilient ad-hoc application clustering, non-Internet P2P, like Freifunk but everywhere. We shouldn't have to depend on Google or any of the big tech companies for anything except the hardware.
That would offer much more freedom. There are also contexts where this kind of thing could also enable life-saving applications. And unlike todays Internet where a database query in Cloudflare or a DNS bug in es-east-1 can disrupt half the services we use, this kind of technology really could withstand major attacks on infrastructure hubs, like the Internet was originally designed to do.
If you said that they'd effectively all be running either a port of OS X or a Linux distribution with a non-GNU but open source userspace, I'd consider that a somewhat unexpected success of open-source software. I would not at all expect that it would be as locked down as video game console.
The more time passes, the less I use my phone for, and the more likely I am to whip out my laptop to accomplish something, like it's 2005.
(if dumbed down) What's are the gaps in features and functionality between what you're describing and what might be achievable today (given enough software glue) with an SDR transceiver and something like Reticulum [1] on an Android?
SDR + something like Reticulum or Yggdrasil would definitely provide the infra or network fabric for the kind of thing I'm thinking of.
However, a normal Android, e.g. a Pixel 7, can't to my knowledge be turned into a web server or a podman host for containers. (I know of people hosting websites on old Androids that are flashed or hacked).
Given phones already have a WiFi/WLAN radio chip, it's a shame to need extra kit for connectivity.
It's something that's been on my mind a lot recently and so you provoked me into writing down a series of scenarios in story format that illustrates what SHOULD be possible using current hardware, were it not, as dlcarrier says, locked down like a games console.
Here you go:
https://ianso.blogspot.com/2025/11/what-we-dont-have.html
For my use case it's beyond great, albeit the small screen and the aarch architecture I can develop small projects as if I was on my PC.
My current phone OP13r doesn't is supported yet by PmOS, when someone does it Im gonna try to install it on one of the slots.
Noteably OnePlus 13 and Pixel 9a, both 2025 phones, can be unlocked.
https://pastebin.com/Wq4fWyvj
If anyone wants the code for scraping and reformatting, let me know.
Imagine if every laptop manufacturer had not a couple of incompatible sensors, but a whole unique boot system only allowing you to boot a crippled version of Windows ME.
It’s really too bad that ARM had adopted ACPI as part of their SystemReady certification. It does work, and not reinventing the wheel is always a wise where feasible, but I think we could absolutely push something better.
The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.
That means that at least the initial bringup for a second-stage bootloader is incredibly easy, less than 40 lines of assembler code [1]. And when you write a tiny operating system, as long as you're content with that basic foundation of 640x480 and text output, it will run on any x86 compatible PC or server.
On anything ARM, that's outright impossible to do and that is a large part of the problem. ARM is power efficient, but it comes at a serious cost. The low level bringup will be handled by the board's ROM, similar to PC BIOS/EFI, but after control is passed to the OS it gets different - all the OS gets is the devicetree stating "here's the memory addresses and interfaces of the hardware in the system", but you still need to write drivers for each and every individual thing from the bottom up, there is no framework for even most basic hardware interactions.
[1] https://gist.github.com/MyCatShoegazer/38dc3ee7db9627ff3a20e...
[1] http://www.techhelpmanual.com/106-int_09h__keyboard_interrup...
[2] http://www.techhelpmanual.com/228-int_16h__keyboard_services...
[3] http://www.techhelpmanual.com/58-keyboard_shift_status_flags...