Google shifting to “upstream first” Linux kernel approach for Android features | Hacker News Reader

Google shifting to “upstream first” Linux kernel approach for Android features

phoronix.com

211 pointsrbanffy112 comments

This seems like the natural lifecycle.

1. There are many features that we feel very valuable to our OS, so we will implement them and ship our OS without blocking on upstream approval and acceptance. 2. Maintaining these patches is expensive. We will try to upstream as much as possible. 3. Most of our patches have been upstreamed and most new kernel requirements are lower priority, we should prefer to upstream first to reduce the cost to migrate our OS from the original implementations to the upstreamed implementations.

At no point does it seem that the decision was "wrong". Obviously carrying a bunch of patches has downsides but at the earlier points in the OS lifecycle getting the features was probably much more valuable than the downsides were harmful.

This lifecycle also has the natural benefit of letting the earlier, more product essential patches stew and iterate for a bit before finally maturing and being pushed upstream. Nobody in the process wants to revisit a big patch a couple months after finally getting something upstreamed to find that 70% of it has been replaced by something better or different, and now the upstreaming of that is a big pain and causing kernel churn. Letting big stuff mature in a large extra-kernel ecosystem (such as android) is good for everyone (as long as it actually does make it into the kernel eventually if it's good).

I remember Google went through much the same process with their own private server kernel fork.

I am afraid it does not matter any more, at least not for practical software freedom.

Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset.

It's an awful situation for people who would rather install software provided by a third party onto their hardware (due to not trusting the device manufacturer enough to only include software in their best interest, which is a very reasonable stance in my book), but I don't think there's a way out any more.

> your bank's Android app

Worst comes to worst you can decompile it and take out the checks, but it is admittedly a huge hassle.

Not really. Safetynet runs on Google servers and communicate with your banks servers (if they have that enabled). If a modded app removes these checks, the bank will notice because they ask Google whether your device fulfills all requirements.

You can't really do that with safetynet, as it relies on sending an (often signed with a hardware key) payload to the servers of the app, which then connect to Google's server for validation, before allowing access to the APIs the app requires.

The checks I've seen when I have explored the possibility of doing this (in an explicitly legal way, I had permission) were easily bypassable client-side. It's not generally a good idea to assume the heaviest option was picked when a simpler one could also have been picked.

The problem is SafetyNet uses remote attestation. And if the bank app is implemented properly that won't work because the server will check they attestation and fail your login. They very well may not bother with this though since they offer a web version anyways... which kind of makes the whole idea of putting root checking in the app pointless.

Right now at least, there's no hardware attestation on many devices so you can just install Magisk and hide the fact you're rooted pretty easily from SafetyNet and still pass.

> Right now at least, there's no hardware attestation on many devices

How long do you think it will be before a country requires that all smartphones support this? And how long before it is a requirement for laptops too?

not sure about smartphones but Windows 11 will require a TPM, presumably for remote attestation

That's a good point. Anyone who suspects that the government pressured Apple to add on-device file scanning (under the guise of "think of the children") should also conclude that making TPMs a requirement is intended to lay the groundwork for a future legislative change (presumably under the guise of "cyber-security").

Replacing OEM Android is only one part of the equation. There are many components that run with full privileges (EL2/EL3?) outside of Android and never subject to Android's sandbox. Well, at least until Google can force OEMs to stricter standards with their effort to KVMize those privileged executables [0].

If you do not trust the OEM, replacing its ROM with GrapheneOS / CalyxOS / LineageOS isn't going to help much anyway.

One right answer to this is fully open-source (hardware and software) phones like the PINE64 and Librem, among others.

[0] https://lwn.net/Articles/836693/

I'm happy with my degoogled phone. There are so many great open source apps on f-droid. Still, it's 2021 and I need a few closed source apps on my main driver, so Aurora Store, MicroG, AdAway. Ok so I'm still using google servers for push notifications of the closed apps--compromises. I still have way more control and battery life. I love the idea of a linux phone, and maybe I could sacrafice the last few closed apps, but what I hear from users is that the hardware sucks. I want a nice phone.

you can get something like ubports on a poco f1. the apps will probably be lacking for you though

> Most Android devices these days have bootloaders that cannot be unlocked

[citation needed]

I'm finding the majority of devices to be unlockable as long as you don't buy your device from a carrier.

Carrier locked devices are not typically the norm but in the US.

And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place.

I really wish people would stop griping about losing security features when you flip the one switch that ensures the security of the system. Unlocking the bootloader means it is now possible to modify system files. Of course Safetynet is going to fail. The point of Safetynet is to ensure the system hasn't been tampered with.

However, despite all of your doom and gloom posturing without actual examples, I've yet to actually use a single app (and I use several banking and root detecting apps like remote features for my car) that will prevent me from continuing to use the app if rooted. It just pops up and says "We see you're using a rooted device, this is not recommended." I click "OK" and proceed as normal.

The alternative is to use Apple and whelp, that'll never happen... since I actually do care about software freedom.

> I really wish people would stop griping about losing security features when you flip the one switch that ensures the security of the system. Unlocking the bootloader means it is now possible to modify system files. Of course Safetynet is going to fail. The point of Safetynet is to ensure the system hasn't been tampered with.

That's pretty much drinking the DRM koolaid. You can have both, verified boot and freedom. All it takes is a mechanism to replace the manufacturer's trust root with an owner-supplied one. The process would wipe anything secured by the trusted components (including keys securing the user data) but that should be fine since you can make a backup.

The only thing that wouldn't work is software that wants to ensure that the user has no control over the system - DRM or "the user is too dumb to be trusted with their own device" security theater.

It is no longer a security theater when the user gets a malicious app installed, that takes over their bank management app.

Changing the root of trust doesn't mean applications can suddenly take over other applications. It also requires granting the malicious app sufficiently elevated permissions for that takeover. The user made several choices along the way. If your argument is that there's the possibility that they could make the wrong choice then this is in my opinion security theater because it posits that a thing can only be secured by taking away choice and no other way.

On this kind of devices the security chain of trust needs to take into consideration the same kind of users that fill their Internet Explorer with random toolbars from website popups.

Not the user with a CS degree that knows what they are doing.

Those kinds of users are unlikely to replace the root of trust, simply due to the process being onerous.

And even if everyone were to install malware. There are other ways to secure banking. E.g. by providing an external token with a display. This is how hardware crypto wallets and some PIN generators for in-browser banking work. Or they could ask the owner to upload the attestation pubkey to their website, then the bank could still check if it's really their app that's running (as confirmed by the boot trust chain). I'm not sure how fingerprint scanners are tied into secure boot, maybe they could be used to verify user intent too.

Okay, so the app's running.

Except the app is remote-controlled by a malicious “display driver” that waits for the user to do all this authentication set-up, transfers the money away, “are you sure”s it, then prevents the user from seeing any of the on-phone scam warnings until it's too late to reverse the transaction.

Display driver is part of the kernel, which is part of the trust chain.

Substitute “display driver” for a draw over other apps, “tap this dot” game, then.

That's a standard feature and not related to unlocking the bootloader. Handling that properly wrt. sensitive apps has to be done anyway.

"Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive." - C.S. Lewis

Freedom to do what you want with the device you purchased is a right that is not to be infringed upon, especially not for the reason "the users might hurt themselves".

Setting up a technically nontrivial flow to unlock the bootloader (e.g. connect the device to a machine with an SSH client, approve SSH connection request with scary message, SSH to the phone, execute a shell script that tells you that you shouldn't unlock this unless you know what you're doing, and after confirmation the script unlocks the bootloader) is more than enough of a deterrent for the vast majority of non-technical users.

The remainder are acceptable casualties - people who refuse to read warning labels are going to have other bad things happen to them anyway (drinking poisons, injuring themselves while working with power-tools) as a result of their foolishness, and the solution to that is not to take away the power-tools from the whole population, but to train them to read and follow warning labels in the first place.

Those technically skilled users who want to unlock their bootloaders (and, you know, do what they want with the devices they paid for) should not have to pay for the stupidity of a small minority of foolish people who refuse to read warning messages.

As it is a right for a manufactures to sell their devices configured as whatever they feel like.

The consumer has the right to buy from companies that sell products that actually fit their purposes, like I don't know, a computer, instead of trying to replace the firmware in a toaster.

As a society we have already decided that manufacturers can't just configure the devices they sell however they feel like. One of the most obvious restrictions is on how they configure any radios. fouric is merely arguing that there should be another, and you're not responding to their points.

As such, your comments in this discussion, and this one in particular, do not appear to be in good faith.

Good example.

Hence why radios are kind of locked down to makers that could make use of illegal radio frequencies, some of which could even be damaging to human health.

My faith is that not everything with a CPU has to be open to install Linux on it.

> And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place.

This irks me. Not everyone has such choice about what to buy.

> This irks me. Not everyone has such choice about what to buy.

Not an excuse anymore. Motorola has universal devices that work on all carriers. Including the most difficult ones in the US, Verizon and AT&T. The unlocked Motorola devices are also often cheaper than getting a device through a carrier.

It has not been an excuse since 10+ years ago in the US.

> Not everyone has such choice about what to buy.

There is always a choice. There are multiple devices at given price point.

Taking credit to buy a mobile is not a wise choice ever.

I trust an unlocked Chinese phone with Lineage OS a lot more than whatever it came with, whether that's for speed, features, security or robustness.

> Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset.

Googles own devices not only allow you to unlock the bootloader, but to relock it with your own signing keys. So your statement is just wierd - if you care, vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for.

Except Pixel phones are not officially available worldwide.

> Googles own devices not only allow you to unlock the bootloader, but to relock it with your own signing keys.

And does it let you pass SafetyNet and run most of the apps. AFAIK it's not so re-lockable bootloader is useless.

I use a pixel phone with my own signing keys and I find it very useful. I can live without SafetyNet, whatever that is.

It basically allows you running most banking apps (and anything that is related to money).

Where I live, both of my banking apps work without SafetyNet and even Google Play Services. I have missed one or another app for having no Play Services, but nothing too important and it's offset by having the option to block all internet connection for other apps.

I have a unlocked booloader and I bypass SafeyNet just fine.

For now. Once SafetyNet start to require hardware attestation you won't be able to bypass it with Magisk.

>vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for

This isn't always possible or realistic. The cheapest Pixel phone is worth 2+ median monthly salaries in my location.

Premium features, premium price point.

Are you content that full ownership of the device is a "premium feature"?

Think of it the opposite way.

All other devices are subsidized to be just an advertising platform for their producer. Real prices of devices are those that you consider "premium".

So privacy is a premium feature now, that should only be available to developed societies? Okay.

that's not how it should be, that's how it is. The only way cheaper devices are so cheap is by cutting all the corners they can, and turns out one of the corners people don't care to be cut is their privacy and security

Is locking the bootloader cutting corners though? Sounds like an extra step to me.

locking bootloader is a way to prevent you from undercutting their spyware. if there is a spyware, than it is a part of their business model, and every user that got away is a drop in revenue. But their targeted users don't mind to be spied on.

How in the world is this a premium feature? It's a piece of software that can be written once (and only once), with the cost amortized between all OEMs.

Most of Motorola's devices are unlockable, too. I run LinegeOS without Google tools on an $80 discount model from a few years ago.

Xiaomi phones are the gold standard of price/performance where I live and their bootloader can be unlocked.

Obligatory reminder of the state surveillance and censorship baked into Xiaomi products: https://news.ycombinator.com/item?id=28616683

If you can swap the device OS with something more trustworthy, does any of that matter or is there evidence that the hardware itself is untrustworthy?

It is not only about hardware. Lineageos re-uses binaries from the original image. The modem still runs original binaries. The bootloader is also original. Plenty of space to hide backdoors, possibly disguised as bugs.

Oh, I knew the modem issue but not that they were reusing binaries. Thanks.

> vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for.

I believe that the ability of a device owner to exercise the same level of control over it as the company that manufactured it is a matter of consumer rights, not features.

OP said "Most Android devices". You then singled out a specific subset of phones that are only a small portion of the market to claim that OP's comment is "weird".

OP's comment is accurate because Pixels are not "most Android phones". You also don't know whether or not OP already owns a Pixel, so I'd say it's "weird" to tell them not to complain without knowing whether or not they have already voted with their wallet.

Most people with most android devices don't remotely care about this. If you do care, it is reasonable to buy a specific device.

... which is a different conversation than this one.

Still, what's the point in telling someone "to vote with their wallet" instead of complaining? Why not both? Where, if not on HN, should we voice our opinion that tech is going down some path we aren't excited about?

Avoiding Google/FB/Amazon/Microsoft or whatever your megacorp of choice is is becoming increasingly hard, and it absolutely deserves being talked about. As do any other things in which our choices and freedoms continue to be snuffed out, and that point should be able to stand alone, without being weighed against things like "Vote with your wallet" or "But in Y thing we have more freedoms now! Why does X matter?" These conversations are also worth having, but they shouldn't entirely replace the a call for alternative paths.

> but I don't think there's a way out any more.

The poster wasn't just complaining about "most phones" but claiming there was no solution.

It seems perfectly reasonable to point out that there is a solution that works at both the individual and global levels. If you want to control your own android devices, there are several good options and if more people start making those choices then the overall situation will also improve.

The general problem I have (personally) with these type of complaints is that there is no real way for any of these companies to act on it further. In the case of Google, they already have acted on it. It's just noise to them at this point.

If you believe something else is being snuffed out, it would help to mention what it is so people can help you. Because making that statement without context doesn't really stand alone, it's also just noise.

>In the case of Google, they already have acted on it.

And in the case of vendors who haven't...?

Which vendors are those? I could try to name some, but they might not necessarily be the ones you would come up with.

Allow me to rephrase.

You say that such complaints are just noise to Google because they have already acted on these complaints (ie, Pixel bootloaders are unlocked). On that, I think you and I agree re: pointless complaining.

I'm asking, why not continue to complain in an effort to push vendors with locked bootloaders to unlock them? Specific vendors are irrelevant, I'm just curious if you do/don't think people should complain to them, as well.

I don't know what you mean specific vendors are irrelevant, if you're not complaining to anyone in particular, then it's just talking into the void.

You've simultaneously demonstrated a misunderstanding of my comment, and - correct me if I'm wrong - answered my question.

My comment is not about specific vendors and their actions. My comment is only about wondering when, in your mind, is a valid time for people to complain; a philosophical question. That's why the question is broad - is it OK for people to complain about vendors who have yet to take action?

Your comment just now suggests that, yes, contrary to your post complaining about complainers, you likely think it's fine to complain to/about vendors who haven't taken action you'd like to see taken.

I'm not concerned with what's valid or fine or not, this is just if you want a chance to get your problem solved or if you want to waste your own time on a complaint that is to the wrong people. These out-of-context complaints/rants happen so often online that twitter even has a meme for it: https://en.wiktionary.org/wiki/sir,_this_is_an_Arby's

Edit: Your logic in the last paragraph doesn't follow to me, as I was responding to a specific complaint. So that's another reason I can't really give an answer to the question.

Google could definitely act on it further by leveraging their agreements with vendors who ship the proprietary Google components of most Android devices. That risks those vendors reimplementing the proprietary components from scratch though, which would fragment the Android ecosystem further.

False. You just want to meta-complain. c0l0 has pointed out how Google(R) MoronNet(TM) in practice usually negates any benefit gained from how virtuous their kernel maintenance process is.

False.

1. Anti-user mechanisms (SafetyNet) annoy users.

2. Even though SafetyNet may not be as annoying as something like UAC, it still has deep reaching effects[1] since now the standards are proprietary and nobody can make an actual good UI alternative to the garbage dog-slow banking app.

The irony is your stale rhetoric only applies the other way: Users who were saved by "risk analysis" and firewall type systems don't know they were saved and don't care.

1. I assume this attestation is checked on the app's server - I assume Google signs their attestation that your device is "good" and this is verifiable by the server of the banking app. Otherwise the in app checks could just be nopped.

I think it matters because the maker of the OS also makes the Pixel, so the Pixel line can be considered the “reference hardware” for Android.

If other manufacturers decide to ignore the reference... well, that’s bad, and worthy of criticism, but it's at least good that the reference is open!

Most I see are unlockable, but then I’d check first anyway.

> And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset.

There is still MagiskHide, though it often requires a bunch of trial and error to get it working. In addition, there are still banks with apps that allow you to install them on rooted devices (N26 in Germany is such a bank).

as far is i know, the main(almost only) magisk developer got hired by google this summer, so it's likely there won't be magiskhide anymore

Thanks for the info. Looks like it will indeed be dropped, [0] has some more details. I stopped using it because the whole cat-and-mouse game that is mentioned was too annoying for me as well, probably a lot worse for the dev.

[0] https://www.xda-developers.com/magisk-development-continues-...

While this won't solve all problems with practical software freedom, it's still an important step into right direction, which will definitely help the free software ecosystem.

You can still buy phones with bootloader which can be unlocked, such as sony[1], but I agree that most doesn't have this option.

The fact that google's proprietary services are necessary for most proprietary applications to work doesn't mean that there isn't a value in a phone running kernel which is closer to an upstream. When you run a custom operating system based on linux kernel, you are less likely to run the proprietary google services anyway.

[1] https://developer.sony.com/develop/open-devices/get-started/...

Sony? Who promise only 2 years of security updates on their 1300€ phones, which turns out to be only 1.5 years after their usual delay to HW availability, and for most of their better phones they never provide any open source support? Nope...

> I am afraid it does not matter any more, at least not for practical software freedom.

These new policies allow more "cross pollination" between mainline linux and the fork used by android. Waydroid running smoothly on an unmodified kernel is a result of this.

Waydroid is important "for practical software freedom" because it allows pinephone and librem-5 to run android apps.

> Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app

I don't think that installing your bank's app is a good idea. First, banks are interested in collecting as much data about their customers as possible so the app will be used as a spyware. Second, installing an app eliminates second factor for authorization - now if your phone gets hacked, the criminals will be able to steal all your savings.

It is better to use only bank's website from desktop computer and use a phone only as a second factor to confirm transactions.

I wish I could upvote you more.

There's nothing about "freedom" in this post, it's all about developer's convenience. It's easier to keep local changes and push them later if the upstream is not changing much. If your upstream is a moving target, doing anything but upstream-first is only making it worse for yourself in the long run.

Nothing to add regarding bootloader locking and safetynet on top. I don't want multiple phones (I actually don't want one), but I was forced to to install my banking app 2nd factor app. I cannot root it, I cannot remove GA, safetynet prevents me to reflash it with something else, even though I theoretically can.

The best part is that at some point you can choose between:

- old/vulnerable/unpatchable android with safetynet => banking apps will be happy to work with it

- new fixed android which is safer, but won't pass safetynet

Yeah.. "safety".

Instead of replacing your phone, have you thought about replacing your bank? Is there any competition that does not force this bullshit onto it's customers?

Yes. I couldn't. The alternatives were worse. I need remote banking (travelling too frequently). No alternative allowed plain login without a second factor.

I've seen other banks here _charging_ for the hardware OTP dongle separately. The yearly price of the dongle was more expensive than simply getting another crap phone and installing the app.

> I don't think there's a way out any more.

Whenever you estimate something bad to be inevitable like this, please consider the many terrible inevitable things in the past. Those in the past thought they were inevitable, but they weren't.

- everyday violence on a much higher level than today

- inability to correct mistakes of government in the long run (voting, free speech)

- lack of power of women

- vulnerability to many diseases

- protection of law

I think any one of these is composed of many traditions that when I think about them seem almost impossible to come about, in the same way that an evolved animal seems remarkable: how did that ever happen? They do happen! People worked hard and incrementally to make them happen.

Estimating them to be inevitable I think can be a discouragement to that hard work.

> I am afraid it does not matter any more, at least not for practical software freedom.

The reason Google appears to be doing this is not software freedom, but enabling longer software updates. Google themselves cannot provide anything remotely competitive to iOS updates if Qualcomm or other SoC vendors effectively keep their proprietary Android builds hostage. Getting stuff mainlined and unshackling Android kernels from vendor shenanigans is a very, very important step. The Google Pixel 6 is the first time in a long while an Android phone excites me, just by virtue of Google's credible 5 years of update promise.

To your point: practical software freedom has been very, very hard on Android from the start. Smartphones are complex devices, and the custom kernels they run have barely been successfully reproduced anywhere else. You can find a small handful of old devices that you can get up and running in a somewhat acceptable state, but you have to restrict yourself to hard to use old stuff to get anything workable at all.

While more software freedom is not really a goal of this project, this does potentially have side effects of more software freedom down the line. Similarly, Google's Project Treble has not delivered everything people wanted, but does allow people to run say (a buggy version of) Ubuntu Touch on a fair number of Android phones [0]. In the Android ecosystem, you have to count your blessings. (And hey, it's not iOS or Windows Phone either!)

[0]: https://forum.xda-developers.com/t/gsi-arm64-a-ab-ubuntu-tou...

I hope they can get SoC vendors onboard. Broken & old BSPs are really tiring, as is waiting for the small user community to slowly upstream all that work. It can take years for the support for a new SoC to mature in upstream Linux. The companies building products upon these SoCs are kinda between rock and hard place, and I think this shows for the user as well (you get old kernel with little to no security updates? it's because you're using a hacked up BSP).

The SoC vendors are doing this on purpose, in order to increase sales. Planned obsolescence. They will not change that without significant pressure.

With Google's eventual transition to Fuschia OS, the skeptic in me sees this as little more than an easy PR win before they begin to wind down new Android development.

But finally this happened. The issue has been around for years. I think (hope) this will dramatically improve the update situation on Android. I wonder though how close Fuchsia is for day-to-day use on current phones

I'm afraid vendor BSPs will be a shit situation for until the end of time, since they are still allowed to ship custom kernel modules - which means when Google updates the kernel, the modules will also have to be reworked (since they live outside of the kernel, they don't benefit from upstream rework effort), and most vendors will take their sorry sweet time to do so or do nothing at all.

Really, I don't get why Google with all its financial and legal power hasn't made sure from the beginning that all manufacturers should open source their kernel code, datasheets etc. - this would have prevented so much e-waste...

Whilst I completely agree with you (alas) and frankly I am not sure I want to see Fuscia succeed (entirely for ideological reasons -- I believe in the value of the GPL) -- this part of you statement has a very clear answer:

> this would have prevented so much e-waste...

E-waste is effectively profit for the device manufacturer. Discarded phones mean that the whole portable computer that is still more powerful than what we had in universities 20 years ago has become worthless and needs to be bought again. It's created an income stream for the manufacturers -- and that's why they're not incentivised to fix these problems. I'm using a OnePlus 5 -- officially EOL and Obsolete! -- with modern LineageOS Rom and it flies. Of course, "official" apps don't like that at all (which is downright stupid of its own reasons), but I have got around that.

I'm sure OnePlus would rather that I threw the thing away and bought another shiny model to get Android 11. Frankly, I'll use it until it breaks and hope that the FairPhone people have caught up by then...

On the other hand I'm much more comfortable buying a 500$+ phone from OnePlus that gets updated for 5 years. Maybe it can turn out to be good for both sides with manufacturers selling more high-end devices. (Rather than designing and selling cheaper but many low-end throwaway devices)

I would imagine it'd be a win for phone SoC-based SBC makers.

While no one can predict the future, I don't think the success of Fuschia is a given. The transition might open Google up to the usual potential missteps and allow a new competitor(s) to enter the space (hopefully).

If it's PR, seems like a lot of effort for a very limited audience

Why is it that nobody seems to be able to spell the word "fuchsia"?

Because it's an unusual spelling. It's a latinisation of the German surname Fuchs (after the botanist Leonhart Fuchs) and is neither pronounced consistently with the surname (Fooks) nor spelled consistently with other words containing the same "sh" phoneme rendered as "sch".

People will never reliably spell it right, so you have to wonder whether it's a great choice of name for an OS.

It isn't only a German surname but the German word for fox.

Even Google misspells it: https://blog.xkcd.com/2010/05/03/color-survey-results/

I checked the other day and it's still true.

> With Google's eventual transition to Fuschia OS

I still have yet to see even the most remotely reliable source that indicates Fuschia is actually going to replace Android.

Reminds me of when people were so absolutely sure that Android and ChromeOS were going to be merged.

Never happened.

I really wish people would stop repeating hare brained tech blog gossip and speculation as confirmed roadmaps.

Maybe some Gerrit commits will help,

https://android-review.googlesource.com/q/fuchsia

Also in case you missed, Android apps now run on ChromeOS.

Code gets shared between projects all the time. Nothing in there specifically says that Fuchsia will replace Android.

In case you had problems comprehending it the first time, ChromeOS and Android were not *merged.*

The rumor has been around since 2015.

https://www.theverge.com/2015/10/29/9639950/google-combining...

Running ones' apps on another OS is not merging the two.

The ChromeOS/Android merger claims are still unsubstantiated. Pretty sure you'd find a fair number of AOSP/Android commits in the ChromeOS repos.

Still not convinced there's any actual evidence of Fuchsia replacing Android here.

that's how rumors work, what rumormongers considered merging of the two OSes, were in fact attempts to make chrome os able to run Android apps, and that's exactly what happend.

In other words, rumors are started because people imagined cross-code commits to be something more than it really was.

Believe what makes you happy.

"RFC-0082: Runnning unmodified Linux programs on Fuchsia"

https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

Again, nothing there specifically puts weight into the argument that "Fuchsia is replacing Android."

And also, Fuchsia's license is more permissive than Android's.

That is exactly the problem. Fuchsia's license is more free only for developers in the short term, as lacks provisions to force developers to keep it free, in the end this will significantly reduce users' freedom. If Linux never had copyleft, it would never have had this success.

Lets put it this way, GCC is already kicked out of Android NDK, just like it has been from Apple platforms, and the Linux kernel is the last GPL piece standing on Android.

Meanwhile, Fuchsia is actually slowly testing the waters in production.

https://techlog360.com/fuchsia-os-on-first-generation-nest-h...

It is no accident that Project Treble follows a similar architecture to Fuchsia drivers.

Fuchsia's license being more permissive than Android is exactly the end goal.

It might not come tomorrow, but it will come.

>Maybe some Gerrit commits will help

These commits don't show that they're replacing Linux with Fuchsia, they show that they haven't killed Fuchsia.

Indeed,

"RFC-0082: Runnning unmodified Linux programs on Fuchsia"

https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

> I still have yet to see even the most remotely reliable source that indicates Fuschia is actually going to replace Android.

Let’s come back in at least 8 years or a decade and we will see if ‘Fuchsia’ actually replaces Android and even ChromeOS then.

I won’t be surprised if they do, given that is where they are heading.

Reply on news.ycombinator.com