Hacker News Reader

Comment by jraph | Hacker News Reader

This is the kind of shit I thought could theoretically happen and it was one of the reason I got rid of Android a few years ago and got a PinePhone when my smartphone died. I've been counting on the Linux mobile ecosystem to develop so we have an good alternative to Android and iOS.

It's not there yet. I need my phone to be reliable and IMHO, it would need to reliably let me place an emergency call if I ever needed it. It's not yet the case. For now, I'm using my first phone, which is not a smartphone, and the PinePhone serves the smartphone-specific needs I have on the go like look something up on the internet or display a map. Which is already something.

The Linux mobile ecosystem has greatly improved though, I still have hope that it'll be usable in a few years.

View on HN

There are no real alternatives. I'm installing apps on a factory reset Samsung A40 from 2019. The last ones of all the process are banking apps, github (only because they decided I need 2FA (*)) and a digital identity one for my country, basically another 2FA. I really don't have an alternative for them. In theory I could leave an Android phone in a drawer at home for those apps, use WhatsApp web on the Pine, maybe Telegram desktop, maybe Gnome maps or Google Maps web, but I'm not paying for two devices.

And the PinePhone Pro is a brick: 160.8mm x 76.6mm x 11.1mm and 215 grams. I'm looking at the 11.1 mm and the 215 grams. Granted, 200 grams is becoming worryingly normal for the new flagships but it's still a brick and those flagships are bricks too. I'm not buying something like that. If they want me to go around with 200 grams in my pocket they pay me. The A40 is 140 grams. I'm afraid there won't be alternatives for that in a few years too, and I don't buy stuff from Apple or one of the old SEs would be a solution until they will also grow big and fat.

(*) I'm also not logging in into GitHub since they forced me on 2FA, because of the extra pass. I currently don't need it for my job and I don't have to open issues to open source projects. The first time I'll have to I'll count to ten and see what to do.

I have a PinePhone Pro, it's not too bad really. It's quite large for someone who wants a tiny phone but PinePhones are still experimental devices and its form factor is kinda the least of my concerns. I'm sure various form factors will follow with a mature Linux mobile ecosystem.

FYI, you can use oathtool on your PC for 2FA, you don't need custom apps for that.

That's not going to work with my bank, maybe GitHub?

I googled and found this from HN https://news.ycombinator.com/item?id=35083499#35086708

I'll give it a try. It doesn't change that 2FA is a pain and I'll log into GitHub only if strictly necessary. Maybe reduced logins are part of their security plan.

2FA mule.

Makes all of this very simple.

The Pinephone can suffer from the same issue where people maintaining the software included may decide they no longer want to maintain their software anymore. It's no different for this. Either someone needs to step up to mountain it or you replace it with something else. Wanting to get rid of the rest of Android just because dialer and messenger are no longer maintained is throwing the baby out with the bath water.

Pinephone has multiple compatible os-s, while most android phones don't have alternatives and become unusable if android drops support for them. Also, Google and the big OEM-s have the incentive to break compatibility to provide you with the newest gadget, which is not true for the pines. yet.

Plenty of android phones have alternatives. It's what custom roms in the title of this article is referring to.

But these custom ROMs are hard to maintain especially as soon as when the phone manufacturer drops support.

There's no way to get the latest AOSP on these devices forever. Hard work is required to port any new version and that's not always possible because AOSP comes to rely on newer kernel versions but you are stuck with the heavily customized one (+ the blobs) the manufacturer provided.

Ever tried LineageOS, /e/OS, GrapheneOS or CalyxOS?

Of course you need to choose a supported phone, but these days there are plenty. And those alternative ROMs are getting really, really good. I have been running /e/OS for two years and I can't tell you a single thing I cannot do because of that (maybe a banking app started crashing once, and after I updated it, it was fine?).

The biggest thing really is that instead of Google Maps, I use one of the awesome OSM apps (Organic Maps and OSMAnd, in my case). And maybe it takes a little bit longer to get a GPS fix (I'm talking a couple of minutes, sometimes).

Yes, I have. I know all this. I also know that the phone I was using back then is discontinued from what I can read from the LineageOS website. Which should not happen for a 7 years old device. And in any case, I strongly believe I should not have to use proprietary drivers.

> And maybe it takes a little bit longer to get a GPS fix (I'm talking a couple of minutes, sometimes).

That's probably related to A-GPS. The modem should be able to receive A-GPS data from the phone. It might even be able to fetch this data by itself. Have you tried microG? I had no such issues when I was using an Android phone with Lineage / microG.

> That's probably related to A-GPS.

Yes that's what I think, too. I use microG, and it's using the "Mozilla Location Service" (which could use some love, maybe?).

Also it's not bad, just a bit slower than Google phones (but Google is really good at tracking, so I expect their A-GPS to have better data, I suppose) :-).

I would export A-GPS [1] data to be the same for everyone. It's just orbital data about the satellites that the GPS satellites also send you, but at a speed of 50 bit/s and you have to wait for the satellite to start broadcast it. As a consequence, it would take about 10 mins to have a fix, while it is instantaneous when the data is already there because it was downloaded beforehand. This data is typically provided by Qualcomm for phones based on their chips, but I guess this data is provided by many other companies.

This is how you would typically do it on a phone running mobile Linux / ModemManager:

    wget -N http://xtrapath2.izatcloud.net/xtra3gr.bin
    sudo mmcli -m any --location-inject-assistance-data=xtra3gr.bin

And I do get an instant GPS fix on the PinePhone Pro with this.

I don't know how it works on Android, I didn't know how this stuff worked back then, I would expect something in the OS to fetch and inject A-GPS data on a regular schedule but that might be something to look into on your side. Some devices are just worse than others when it comes to get a GPS fix, regardless the OS.

https://en.wikipedia.org/wiki/Assisted_GPS

Oh, I thought it relied on stuff like WiFi/Cell-based localization. Now I wonder if something is wrong with my software, or if the Fairphone 3+ is just slow at getting a GPS fix :)

Not for the GPS fix. Now, location is done both with GPS and with WiFi/Cell indeed.

Wow... people, can you please just read a bit about AOSP before dropping such complaints?

There is no "Android drops support for them". It's "Google drops support for them". Google maintains AOSP, but if they stopped doing that, probably AOSP would survive in some form. Also I am not convinced that companies like Samsung would be happy to go with a completely proprietary Google OS, so chances are that they would get more involved into AOSP.

Pinephone has nothing to do with the OS, it is a smartphone. You can install Linux mobile distros (like PostmarketOS) on many mainstream phones (like Samsung, etc), and you can install Android on your Pinephone. That is completely orthogonal.

Not really.

To run Linux mobile distros on regular Android phones, you need to have an Android base because essential features of these phones are implemented in closed source user space drivers that expect an Android system. You are basically stuck with the kernel your phone came with, plus some of its user space. That's what libhybris is for.

In practice, development of this is slow as far as I know, and you need someone to port your specific device to it so you can run linux distros on it. But distros maintainers are more or less focusing on the Pinephone and the Librem 5 now that devices not requiring such blobs.

As for running Android on the PinePhone, that's technically possible but in practice not much works AFAIK because people are focusing on the Linux mobile ecosystem instead.

> There is no "Android drops support for them". It's "Google drops support for them".

In which ways the distinction is useful? In any case, when your Android phone manufacturer drops support for your device, you are pretty much stuck on your heavily customized Linux kernel and your closed-source userspace drivers that expect this old kernel and its specific patches. They also expect the specific version of Android the phone comes with because Android may change APIs and drop features they are relying on. Porting to newer Android versions is not always impossible, but it's hard work.

The PinePhone I boot in 2020 runs the latest mainline kernel, which is the whole point of this kind of device.

[1] https://en.wikipedia.org/wiki/Libhybris

Sorry, I am not completely sure I understand the point you are trying to make.

Yes, devices that work with the mainline kernel are better supported. Both for Android and for Mobile Linux.

> In which ways the distinction is useful?

Because people not making the distinction tend to conclude "you should move to a Mobile Linux instead". Which is completely wrong: while there are active Mobile Linux projects, there are active AOSP-based projects.

Android, today, is completely functional without Google (I have been running a de-Googled ROM for 2 years). I played a lot with PostmarketOS, and while it is very cool, it is still very, very far from Android. Even more so if you don't run waydroid and hope for people to write good mobile apps with some kind of C++ cross-platform framework like Qt.

> Android, today, is completely functional without Google

I know, I have used microG and all that stuff.

My point is that the way they are produced, Android phones are not built to last / be kept up to date. I don't believe it's a problem with AOSP proper, I could run the latest Android on a 12 year old intel tablet (difficult with 1G of RAM, but still). But that's because it can run a mainline Linux kernel when no Android phone currently can.

> My point is that the way they are produced, Android phones are not built to last / be kept up to date.

Agreed, most Android phones are not built to last. Some are, though (I own a Fairphone, for instance). And some mainstream Android phones (talking Samsung and the likes) are maintained by custom ROMs like LineageOS. I mean GrapheneOS explicitly targets the Pixel line.

Also projects like PostmarketOS have been mainlining many phones, I think. I would guess that this also benefits Android?

Fairphone does make impressive efforts toward this direction indeed. Their push towards more ethical manufacturing is also great. I which their phone didn't rely on proprietary drivers.

> Also projects like PostmarketOS have been mainlining many phones

There's only so much they can do, but if they manage to mainline Android phones, that's obviously great news for their owners, including if they want to stay on Android because this probably eases porting new versions a lot.

The difference is one is planned. Google promotes dependency on their services. There are alternatives to gapps. There are also alternatives to paved roads. The problem is they add more hoops to jump through. They care about the 99 percentile. Those won't keep chasing said hoops.

While large orgs help maintain relevant FOSS, to them, AOSP is left to rot. In our case, several k employees, we have teams dedicated to relevant FOSS tools. My wife, at a startup, have 20% paid worktime a week to contribute to whatever they want.

Your analogy, at face value, makes sense. Adding a few more lenses to the analysis weakens it severely.

> There are alternatives to gapps. There are also alternatives to paved roads. The problem is they add more hoops to jump through.

Because going for a mobile linux distro does not involve jumping through hoops?

> While large orgs help maintain relevant FOSS, to them, AOSP is left to rot.

Not sure what you mean by that. AOSP is still maintained, and there are quite a few de-Googled ROMs (LineageOS, GrapheneOS, /e/OS, CalyxOS, ...) that are really becoming very good.

> Because going for a mobile linux distro does not involve jumping through hoops?

Parent said "add more hoops to jump through".

We are speaking about the direction and intents. Google makes it harder and harder to avoid the Google ecosystem.

Mobile Linux does not add hoops to jump through. The intent is making things easier as time passes.

Of course today all this is still experimental and of course you need to jump through many hoops.

> Not sure what you mean by that. AOSP is still maintained

Yes, the base system is still maintained, but the concern is that Google increasingly adds features into proprietary gapps instead of AOSP proper. And the post we are discussing is exactly a sign of this tendency.

> Parent said "add more hoops to jump through".

But parent was talking about a comparison with running a Linux mobile distro on a PinePhone. Using PostmarketOS or similar (and don't get me wrong, I find PostmarketOS very cool) is still orders of magnitudes harder than using a custom ROM like /e/OS or CalyxOS. And those custom ROMs are improving fast, too.

> Mobile Linux does not add hoops to jump through. The intent is making things easier as time passes.

Same for custom Android ROMs. Except that they are already much more usable than Mobile Linux.

> Yes, the base system is still maintained, but the concern is that Google increasingly adds features into proprietary gapps instead of AOSP proper.

Google's strategy and lock-in with the Play Services is nothing close to a surprise. But again, I think dropping support for those two (basic, let's be honest) apps is really not a problem.

Actually a bigger problem, to me, is app developers who rely on the Play Services because it's easier for them, and because they don't care about custom ROMs. And of course Google pushes for that, but in the end, app developers can pretty easily do their part to not make life more difficult for custom ROMs.

> But parent was talking about a comparison with running a Linux mobile distro on a PinePhone

But the comparison works. No mobile linux distro adds hoops to jump through.

Of course (Almost?) nobody thinks that mobile linux is as convenient / usable as Android right know.

For many of us it's about developing an ecosystem that's truly open source / that does not rely on Google.

> But again, I think dropping support for those two (basic, let's be honest) apps is really not a problem.

No, indeed. The custom rom will survive. There seems to be correct alternative apps, and someone might even put the effort in maintaining the AOSP ones.

It's just a symptom / a clue of the broader issue.

> But the comparison works. No mobile linux distro adds hoops to jump through.

Right. Sounds a bit pedantic to me, but okay :).

I guess my point is that AOSP is open source, and in a much better shape for mobile than Mobile Linux.

It is great to see work going on with Mobile Linux, and I find projects like PostmarketOS really cool. I just don't like how (some) Mobile Linux fans apparently seem to jump on every opportunity to say that Android is doomed and Mobile Linux is the only way.

> Sounds a bit pedantic to me, but okay :).

Ah, the distinction is important indeed :-) The expectation is that things are improving.

I think many people in the mobile Linux do think Android is doomed, or at least is not an interesting path anymore for the long run. That's what drives them. Android works, but has some flaws this ecosystem can't see being avoided. Being stuck with the custom kernel and the proprietary drivers is one of them.

Personally, I'd be happy with an Android phone that can run free of proprietary drivers with the mainline kernel.

Thanks for the discussion :-)

>Being stuck with the custom kernel

Android already works on the kernel. You don't need a custom kernel.

>and the proprietary drivers

If it uses proprietary Linux kernel modules they will still be proprietary kernel modules without the rest of Android.

> If it uses proprietary Linux kernel modules

Librem 5 doesn't use them.

What's your point? If free drivers are available you have the freedom to use free drivers. If they aren't available you don't unless you make them yourself.

My point is that for Linux phones you are free from those Googe-created problems of the long-term support. You simply use the mainline kernel and your device works forever.

> unless you make them yourself

You almost never can write free drivers yourself, because the hardware specs are closed. You would need to do reverse-engineering, which is too costly.

> You don't need a custom kernel.

Most Android devices use a downstream kernel that has modifications that were made specifically for the device. In other words, most Android devices are not mainlined. I guess it is reasonable to call "custom" anything that is not the mainline kernel, isn't it?

A few questions: 1. Given the existence of FOSS alternatives, is it important that these apps live as part of AOSP? It seems to me that this is an improvement as a bad default is worse than no default. 2. Given the apps were not maintained by Google, did anyone else volunteer to maintain them? Has anyone tried to upstream an alternative app to AOSP which will be maintained?

Reply on news.ycombinator.com