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.
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.
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.
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".
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"
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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:
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.
Android/Linux dual boot is a great way to get the best of both worlds—mobile flexibility and full desktop power—on a single device. Ideal for tech enthusiasts and developers.
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.
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.
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.
It's called installing. Language matters and I see no reason to concede this point in Google's favour.
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.
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
(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
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.
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
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.
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
"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).
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.
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 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.
https://pastebin.com/Wq4fWyvj
If anyone wants the code for scraping and reformatting, let me know.
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.
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...