Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

phoronix.com

Post reply on HN
Print view View original

21–30 of 116 posts

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

#21

Post by wizzwizz4 »

techrat wrote: post #16
c0l0 wrote: post #6

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…

> 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 abo…

> 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.

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

#22

Post by izacus »

c0l0 wrote: post #6

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…

> 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.

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

#23

Post by techrat »

wizzwizz4 wrote: post #21
techrat wrote: post #16

Earlier quoted context omitted.

> 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 abo…

> 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.

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

#24

Post by arsome »

krageon wrote: post #11
c0l0 wrote: post #6

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…

> 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.

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.

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

#25

Post by gchamonlive »

izacus wrote: post #22
c0l0 wrote: post #6

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…

> 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 yo…

Except Pixel phones are not officially available worldwide.

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

#26

Post by Semaphor »

c0l0 wrote: post #6

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…

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).

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

#27

Post by SXX »

izacus wrote: post #22
c0l0 wrote: post #6

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…

> 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 yo…

> 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.

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

#28

Post by omnicognate »

vadfa wrote: post #17
noptd wrote: post #2

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.

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.

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

#29

Post by pjmlp »

the8472 wrote: post #20
techrat wrote: post #16

Earlier quoted context omitted.

> 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 abo…

> 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.…

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

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

#30

Post by pjmlp »

techrat wrote: post #18
noptd wrote: post #2

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.

> 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.

Post reply on HN