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

Bringing the Android kernel back to the mainline

lwn.net

Post reply on HN
Print view View original

111–120 of 121 posts

Re: Bringing the Android kernel back to the mainline

#111

Post by mavhc »

tremon wrote: post #109
metildaa wrote: post #72

Earlier quoted context omitted.

The shoddy build quality, plus lack of microSD & heaphone jack means I will never buy a Pixel or other Google branded hardware. My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects. Meanwhile, both of my old Galaxy…

Same here. Galaxy Note II, still going strong. I bought a new battery for it a year ago, expecting the old one to go out soon, but I still get more than three days battery life from it.

My Galaxy S3 died due to a known fault with the flash storage, can't repartition it to fix it

Re: Bringing the Android kernel back to the mainline

#112

Post by noderat »

metildaa wrote: post #72
nextos wrote: post #31

Earlier quoted context omitted.

There's a compromise solution to achieve something equivalent. And I say so after having tried many possibilities. Buy a Pixel or any other phone that supports AOSP (Sony does too, with some caveats) and install plain AOSP. It's not perfect as you need a bit of infrastructure to compile it yourself and keep OTA updates. But it's the most practical secure and privacy-respecting option, I think.

The shoddy build quality, plus lack of microSD & heaphone jack means I will never buy a Pixel or other Google branded hardware. My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects. Meanwhile, both of my old Galaxy…

I have owned since launch day a Nexus 1, Nexus 4, 2x Nexus 6, 2x Nexus 7 and Pixel 2 XL and they are all currently still functional well past their warranty. (The Nexus 1 was replaced by Assurion for water damage with a refurbished device @1.5yrs but replacement is still running.) In fact my Nexus 4 is still in use every day as an APRS GPS receiver/data logger, and one of the Nexus 6s is now in use by a co-worker as a OBD2 data logger/HUD.

I've avoided Samsung devices (including Galaxy Nexus/Nexus S) because the girlfriend has had the last 4 Samsung devices fail or become completely usable right at the end of the warranty (+/- 2mo) running completely stock. For those that became completely unusable it was usually pitiful battery life, the others became too slow to function on stock roms that I suspect they failed due to internal storage wear. Not even custom roms could save them.

I keep my devices a long time, and frequently repurpose them after they are no longer my primary device. Non-Samsung "Pixus" problems are overblown, except Nexus 6 AMOLED burn-in which is annoying but didn't present itself until it was used daily as a HUD.

Re: Bringing the Android kernel back to the mainline

#113

Post by ori_b »

naasking wrote: post #105
ori_b wrote: post #47

Earlier quoted context omitted.

Wouldn't really help -- the biggest result would be that vendors would have less of a reason to release things under the GPL.

That's a non-issue because a microkernel system call interface is stable. Drivers will simply continue to work in perpetuity. That seems like a huge help to me.

Why would you assume that? The set of required messages for drivers will increase over time, adding power saving commands, new hooks for higher level Android bits, and so on.

"Your WiFi only supports Android Kernel API 3.9. You need 7.0 to run this version of Google play".

The Linux kernel already has a stable user space ABI. If your hypothesis was valid, you would be able to upgrade the Android userspace on an old kernel with no problem. But you can't -- and that's with just one well specified ABI with a standardized, portable subset to worry about.

Re: Bringing the Android kernel back to the mainline

#114

Post by paulie_a »

metildaa wrote: post #72
nextos wrote: post #31

Earlier quoted context omitted.

There's a compromise solution to achieve something equivalent. And I say so after having tried many possibilities. Buy a Pixel or any other phone that supports AOSP (Sony does too, with some caveats) and install plain AOSP. It's not perfect as you need a bit of infrastructure to compile it yourself and keep OTA updates. But it's the most practical secure and privacy-respecting option, I think.

The shoddy build quality, plus lack of microSD & heaphone jack means I will never buy a Pixel or other Google branded hardware. My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects. Meanwhile, both of my old Galaxy…

I won't buy anything but pure Google, Moto or lg phones anymore. If they start adding crappy software replacements I will switch. Samsung is a non starter there, hard coded button for bixby is idiotic. Also bixby is idiotic.

Re: Bringing the Android kernel back to the mainline

#115

Post by pjmlp »

derefr wrote: post #8
rsre wrote: post #2

I've always found this curious since Linux fans usually mention the high usage of Android as Linux usage. The people usually think of GNU/Linux when they think about using Linux but the truth is Android is far from that. Be it the lack of GNU utils, not using a mainline kernel or the myriad of blobs and proprietary stuff bolted on top.

Unlike most other environments, though, it is very simple to create an Android application which embeds and launches a Linux userland, without any virtualization or syscall-ABI translation being required. See, for example, https://termux.com/ ChromeOS is also "Linux" in this sense, because of Crouton.

Kind of, https://wiki.termux.com/wiki/Differences_from_Linux

Re: Bringing the Android kernel back to the mainline

#116

Post by chipotle_coyote »

Wowfunhappy wrote: post #70
Mononokay wrote: post #69

Earlier quoted context omitted.

That's a complete lie, but okay. https://medium.com/metodixtech/ios-how-to-downgrade-and-save...

In the first sentence of the article you linked: > You can downgrade (If you don’t have Shsh blobs saved) only until Apple is still signing the old software. Saving SHSH blobs needs to be done in advance, while the iOS version you want to install is still being signed by Apple. With blobs, you used to be able to use a replay attack to force a restore. This doesn't work anymore due to the addition of NONCE, except in…

I'm fairly sure I have seen speed tests between iOS 11 and 12 with actual numbers involved. Someone who has a single phone and upgrades it can't do it, no, but someone who runs, say, a testing lab, or iFixit, or any other place where it's possible to have two different iPhones of the same model running two different versions of iOS can do it pretty easily. Googling "ios 11 vs ios 12 speed" shows a plethora of links from people doing exactly that. I found the same for "ios 11 vs ios 10 speed"; I didn't keep repeating the experiment past that. :)

As to your original point, though -- yes. I'd certainly prefer it if Apple didn't make downgrading so difficult, even if it's just on general principle. I've rarely been tempted to downgrade, but iOS 11 could be pretty clunky on my iPhone 6 compared to its predecessor. (I think 11.4 finally smoothed all that out, but that came out literally a week before iOS 12 was announced!)

Re: Bringing the Android kernel back to the mainline

#117

Post by [deleted] »

chipotle_coyote wrote: post #116
Wowfunhappy wrote: post #70

Earlier quoted context omitted.

In the first sentence of the article you linked: > You can downgrade (If you don’t have Shsh blobs saved) only until Apple is still signing the old software. Saving SHSH blobs needs to be done in advance, while the iOS version you want to install is still being signed by Apple. With blobs, you used to be able to use a replay attack to force a restore. This doesn't work anymore due to the addition of NONCE, except in…

I'm fairly sure I have seen speed tests between iOS 11 and 12 with actual numbers involved. Someone who has a single phone and upgrades it can't do it, no, but someone who runs, say, a testing lab, or iFixit, or any other place where it's possible to have two different iPhones of the same model running two different versions of iOS can do it pretty easily. Googling "ios 11 vs ios 12 speed" shows a plethora of links f…

[deleted]

Re: Bringing the Android kernel back to the mainline

#118

Post by pdimitar »

as1mov wrote: post #78
pdimitar wrote: post #55

Earlier quoted context omitted.

I challenge you to name me one Android device that is officially supported for 4 or more years. ;) iPhone 4 is 8 years old so not sure I see your point.

Why does any criticism of Apple devices generally devolves into "but Android does it too", I expected better than fanboy-ism from the HN crowd. The OP's comment was that any mobile devices these days, both Android and iOS are locked down black boxes. It wasn't specifically criticizing just Apple.

If you followed the dicussion you would see the big "both ecosystems are locked down and you are at the mercy of vendors" thread that goes on around here.

But it's easier to flag people as fanboys.

Since you are having trouble with getting what I said: I am saying that Apple in my eyes is the lesser evil of only two options. It's a very practical and time-saving decision to use Apple tech. But call it fanboyism if you like.

Re: Bringing the Android kernel back to the mainline

#119

Post by metildaa »

noderat wrote: post #112
metildaa wrote: post #72

Earlier quoted context omitted.

The shoddy build quality, plus lack of microSD & heaphone jack means I will never buy a Pixel or other Google branded hardware. My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects. Meanwhile, both of my old Galaxy…

I have owned since launch day a Nexus 1, Nexus 4, 2x Nexus 6, 2x Nexus 7 and Pixel 2 XL and they are all currently still functional well past their warranty. (The Nexus 1 was replaced by Assurion for water damage with a refurbished device @1.5yrs but replacement is still running.) In fact my Nexus 4 is still in use every day as an APRS GPS receiver/data logger, and one of the Nexus 6s is now in use by a co-worker as…

Seems like you missed the horrid bootlooping issues of the Nexus 5x, the bad battery firmware on the Nexus 6p, and the bootlooping and flakey charge controller on the OG Pixel.

Your choice in devices of the Nexus/Pixel series is very lucky, you avoided the defective models nearly entirely. I have no faith that I will be similarly lucky.

Re: Bringing the Android kernel back to the mainline

#120

Post by metildaa »

milankragujevic wrote: post #108
metildaa wrote: post #73

Earlier quoted context omitted.

The funny thing is the SoC in these smartphones can totally run Linux & Darwin, but the driver support for the peripherals is shovelware. Vendors do the bare minimum to suppprt the hardware, and you get a mess. Its frankly shocking that the Allwinner A10/A20/A64 (which can run Win10!) /H3/H5/H6 has nearly complete mainline kernel support, whereas nearly any of the smartphones made since 2008 can't boot mainline Linux…

Allwinner can't run Win10 (hah, A33 can barely run Android :/ ) and has barely any mainline support on actual physical commercial devices (i.e. tablets, not SBCs)...

I don't know what your on about, Windows 10 can run UWP apps just fine on any Allwinner A64 based device: https://github.com/Leeway213/Win10-IoT-for-A64-Release-Notes...

With regard to supporting tablets, most of the older Allwinner based tablets have feature parity between the mainline kernel and the vendor BSP kernel: https://linux-sunxi.org/Linux_mainlining_effort

Post reply on HN