Android-x86 Is Still Working Towards Its 9.0 "Pie" Release

[jo-erlend]

Ask OEMs. This is a discussion of Android-x86 ;-)

I ask you, because you seem to think that the reason they stop supporting Android devices once they've sold them, is because supporting them is difficult. But that isn't really the case, is it? What is the case is that it's very lucrative business to outdate hardware as quickly as possible. I think it's crazy that it's even legal.

[torsionbar28]

I ask you, because you seem to think that the reason they stop supporting Android devices once they've sold them, is because supporting them is difficult. But that isn't really the case, is it?

Yes, actually, build difficulty is exactly the reason. With Android version 1, through version 7 (nougat) the device specific code was tightly coupled with the generic Android OS. That means doing a new build is a substantial development effort for every phone manufacturer, as the build is specific to each and every device, and even to various international variations of the same device. So yes, historically, it has been a big pain in the butt.

Only with version 8 (oreo) released in late 2017, has the Android team begun to decouple the device-specific code from the generic Android OS, so this is a very recent effort.

What is the case is that it's very lucrative business to outdate hardware as quickly as possible. I think it's crazy that it's even legal.

I can certainly see that angle, but I don't believe that casual users really care about this. As long as the device continues to function, they're happy with it, and likely oblivious to new operating system versions. Don't take my word for it - go ask a random stranger or co-worker or friend with an Android phone "Pardon me, which Android OS version and patch level are you running?" and I guarantee you'll get confused looks and blank stares. Most people just don't care about this stuff.

Also statistically speaking, most people replace their smartphone sometime between 2 and 3 years after purchase, so from a cost/benefit standpoint, 2 years of support seems reasonable.

For the true geeks, there is LineageOS or the /e/ project or others that provide newer builds for older phones. FWIW I'm a fan of /e/ and I'm running Android 9 Pie with the latest January 2020 security patches on a nearly *seven* year old Samsung Galaxy S4. So yea, as a geek, there is more flexibility if you're willing to modify bootloaders and flash firmware.

[jo-erlend]

Yes, actually, build difficulty is exactly the reason. With Android version 1, through version 7 (nougat) the device specific code was tightly coupled with the generic Android OS. That means doing a new build is a substantial development effort for every phone manufacturer, as the build is specific to each and every device, and even to various international variations of the same device. So yes, historically, it has been a big pain in the butt.

But that's a completely separate issue, isn't it? The question wasn't how difficult it is to bring up Android on a new device, but supporting existing devices.

[c117152]

Don't be absurd. Intel, the only company that cared, dropped out of the market...

1. Android-x86 has a few corporate sponsors in gambling and entertainment.
2. Intel noticed the above (belatedly, again...) restarted their Android-IA efforts as Celadon but they're targeting device specific from the looks of it though I'm sure some of the fixes will work their way into Android-x86.
3. Android 9 was mostly a cosmetic update with most of the big features (except for the DNS TLS thing) being pushed into Android 10. Even LineageOS 16 only came out in March 2019, 5 month after Android 9 was released back in August. The few big changes regarding the partitioning, device tree and system level stuff just don't matter to end user and only change procedures to OEMs and modders.
4. Android 10 (September 2019) has a lot of useful features and they're likely putting most of their efforts into it. It also resumes google's commitment to mainlining efforts so I'm sure there's some workflow changes going on in the background.
5. They're also pulling (and pushing) changes into LineageOS which reflects Qualcomm specific AOSP sources rather than just AOSP.
6. There were (and are) a few other x86 Android projects that came (and went) that attracted some attention so patches were being exchanged back and forth...

Anyhow, there's plenty more of this going on. But overall, it boils down to slower releases right now and a lot of behind-the-scene work for faster releases in the future.

[skeevy420]

birdie jo-erlend

Y'all are both right. The phone manufacturers are reliant on Qualcomm and other chipset manufacturers to keep on providing drivers. Samsung can't update a Galaxy WhoGivesAShit if Qualcomm doesn't provide drivers for the 510 GPU or whatever past Android 5 which forces Samsung to design a new phone around the 512 GPU that will get Android 5.5 to Android 7 drivers. Once that new version rolls around they can either have their own internal XDA rom hacking team to support older phones with drivers that are no longer supported by their manufacturer or use new hardware that is supported by its manufacturer.

That said, Google has made it easier to re-use old drivers for newer versions of Android which is why you can go to Amazon and eBay and find shitloads of old Android 3 and 4 tablets repackaged as Android 6 and 8 tablets (which has made it fucking difficult as fuck to buy cheap tablets). The problem is that it seems that very few phone manufacturers want to have a long-term rom hacking team to maintain older products because they all make their money selling hardware. Google, who sells software and can get away with shittier hardware sales than everyone else, can afford to keep the Nexus and Pixels and What-have-yous updated longer than LG can keep their other flaghships up-to-date.

The major manufacturers also have more liability than the crap on Amazon which is why they churn out so many phones. Qualcomm drops support, rom hacking team makes drivers use legacy interfaces, new exploit comes out and uses old drivers, phone manufacturer gets in trouble. If they stay up-to-date, however, they get to blame Qualcomm and the liability shifts from them to where they get their stuff.

Then, at least in America, there are the phone carriers to consider. They all want their own special version of a phone and they want a new one every couple of months just so they can say "we have this new phone with 15 razors". That dictates a lot of the trends the assholes above do. Samsung says "why have LTS when those American assholes want new crap every 6 days?" and Qualcomm says "why have LTS when those Korean assholes keep making new crap for the American assholes". This is a case of shit flows down hill.

[torsionbar28]

But that's a completely separate issue, isn't it? The question wasn't how difficult it is to bring up Android on a new device, but supporting existing devices.

No it isn't. Re-read what I wrote. With Android v1 through v7, the effort required to build a new version of Android for an existing device is the same as for bringing up a new device. I.e. it's a major effort.

Or are you asking why old versions of Android don't have LTS status and get security patches for years and years?

[jo-erlend]

No it isn't. Re-read what I wrote. With Android v1 through v7, the effort required to build a new version of Android for an existing device is the same as for bringing up a new device. I.e. it's a major effort.

Or are you asking why old versions of Android don't have LTS status and get security patches for years and years?

I'm only asking why it is not possible for one phone to get a kernel patch when so many others have the same versions of Android and does. You say it's because patching the kernel is the same amount of work as designing a new BSP for a new device for a new version of Android, right? I don't understand why that would be the case. Can you explain it in more technical terms?

[skeevy420]

I'm only asking why it is not possible for one phone to get a kernel patch when so many others have the same versions of Android and does. You say it's because patching the kernel is the same amount of work as designing a new BSP for a new device for a new version of Android, right? I don't understand why that would be the case. Can you explain it in more technical terms?

Because the kernel version used varies greatly from manufacturer, device, chipset maker, etc. Android version is irrelevant in regards to kernels for up to Android 8 or 9 (not sure which) because Google didn't enforce minimum kernel versions until then.

My LG phone, a V20, from 2016 or 2017 still runs Linux 3.x. Then there are a lot of half-ass published kernel sources where they'll release the kernel version used but not any of their closed-door changes that make it difficult to even update a phone from 3.xx to 3.xy. You'd be very, very surprised about just how many different kernels are in use and the efforts that some open source developers do to even bring a device up to using a 4.0 kernel, let alone any kernel past 4.4...it's freakin crazy fragmented on Android.

Nowadays we have Qualcomm, etc moving drivers from the kernel to userspace but then not providing updates when the Android userspace updates -- in the custom rom scene, that's where they'll figure out how to build Android 8 with Android 7's audio stack (just making something up because I've been out of the rom game since around 5.5/6.0) -- but manufacturers can't do that backport effort. Android might be open source, but Google is very stringent on what they'll allow to be called Android and using a fustercluck of sources, kernels, and blobs from 6, 7, and 8 to build a 9 rom is just not allowed and that leaves them in a bind on how to proceed forward...or another line gets drawn and there is further fragmentation of everything.

Android development is a fustercluck.

[starshipeleven]

Then, at least in America, there are the phone carriers to consider. They all want their own special version of a phone and they want a new one every couple of months just so they can say "we have this new phone with 15 razors". That dictates a lot of the trends the assholes above do.

This is true for OEMs too, but the main point here is that having a new phone every 6 months is the only way to get money in a saturated market if your businness model is based on hardware sales and not on services.

If we are going to demonize that, everything not a service and in a saturated market is evil too.

[starshipeleven]

I'm only asking why it is not possible for one phone to get a kernel patch when so many others have the same versions of Android and does. You say it's because patching the kernel is the same amount of work as designing a new BSP for a new device for a new version of Android, right? I don't understand why that would be the case. Can you explain it in more technical terms?

Sorry what, How many Android phones ever get a kernel patch in ever? Afaik only Google devices get them, and only very rarely when it is an actual functionality bug.

The kernel is part of the BSP/SDK and none touches that ever. It isn't vanilla kernel, it's hacked around and has crappy blobs with no shim interfaces (like NVIDIA and Broadcomm blob wifi drivers that allow anyone to adapt the shim to kernel changes and keep the blob happy). Adding patches may or may not break the blobs (upgrading kernel version 99% breaks blobs). You think the OEM has all the source? No they don't, they have kernel source and blobs and documentation with NDAs on it. The hardware manufacturers (that made the BSP/SDK) have the source or otherwise the ability to get updated blobs.

This is the entire reason why Android from 8 onwards with Project Treble has done more shenanigans to isolate more and more from the BSP and allow easier upgrades while not touching the hardware support part of the OS.

The same situation can be found in embedded devices like NAS, routers and wifi access points, a sizeable amount of new devices are still shipped with kernel 2.6 and proprietary stuff on top because the hardware manufacturer does not feel like upgrading their proprietary stuff to run on the newest Linux kernel versions.