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

Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

arstechnica.com

Post reply on HN
Print view View original

221–226 of 226 posts

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#221

Post by phh »

rincebrain wrote: post #170
phh wrote: post #92

Earlier quoted context omitted.

I, as an OSS community contributor, have been using Treble for years now, and I have devices who got let down by their OEMs on Android 8, that I pushed up to Android 11, and that's been pretty cool. I, as an OEM, am still NOT allowed (by Google) to use Treble to provide upgrades. This "legality" issue is being fixed ( https://android-developers.googleblog.com/2020/12/treble-plu... ), but its effect won't reach users…

I don't see anything in your second link that explains what the "legality" issue is, could you clarify that for me, please?

The idea of Project Treble is to separate drivers from Android, and also to version drivers. When you receive a smartphone running Android 10.0, you also receive drivers "targetting" Android 10.0. With Treble, you can replace that Android 10.0, and bring it up to Android 11.0, while keeping the drivers targetting Android 10.0, and this pretty much works.

To release a smartphone with Google apps, an OEM must adhere to some requirements. One of those requirements, is that if you provide to customers an Android version X, then you must provide drivers targetting this version. You are not allowed by Google to provide an Android version 10 with drivers targgeting Android 9. This is true even across updates: if you release the smartphone with Android 9, then upgrade it to Android 12, then the Android 12 upgrade must include drivers targgetting Android 12.

The change that is coming, is that for Android 13, OEMs will be allowed to keep the drivers they made for Android 12.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#222

Post by phh »

PurpleFoxy wrote: post #121
phh wrote: post #27

What about Google? The issues fairphone mention are passing Google certification suites. They should be relaxed to help those cases. As far as I know the major issues are around GLES. It passed older CTS, so GLES was good enough back then. Surely it could be good enough now.

Isn’t gles replaced by vulkan since about 5 years ago? Google wouldn’t want so much fragmentation for app developers to deal with.

Google is slowly working on deprecating/hiding OEM's GLES drivers, in favor of Vulkan, but we're still very far from that.

Most of Android's rendering is still mostly GLES, using directly OEM's GLES driver. Since Android 10, apps can decide to use Angle for generic GLES over Vulkan, but that's opt-in.

Also the Snapdragon 801 chip of the Fairphone 2 doesn't have (official) support for vulkan

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#223

Post by angryasian »

zepto wrote: post #51
angryasian wrote: post #20

Earlier quoted context omitted.

Ok an oligopoly, does that make it better. Apple has a monopoly on Apple silicon.

Apple doesn’t have a monopoly on Apple silicon nobody buys it.

>the exclusive possession or control of the supply of or trade in a commodity or service.

They have exclusive possession or control of supply of these types of chips. I'm not sure if the question of whether or not they could sell or want to sell it comes into question. Lets say I buy up all the supplies of diamonds and exclude the use of diamonds in any other use than my jewelry. I believe this still falls under a monopoly

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#224

Post by rincebrain »

phh wrote: post #221
rincebrain wrote: post #170

Earlier quoted context omitted.

I don't see anything in your second link that explains what the "legality" issue is, could you clarify that for me, please?

The idea of Project Treble is to separate drivers from Android, and also to version drivers. When you receive a smartphone running Android 10.0, you also receive drivers "targetting" Android 10.0. With Treble, you can replace that Android 10.0, and bring it up to Android 11.0, while keeping the drivers targetting Android 10.0, and this pretty much works. To release a smartphone with Google apps, an OEM must adhere to…

I wonder what the motivation was initially, to implement a glue layer that let you keep older drivers functional, only to also require the drivers be updated in lockstep. (Specifically the benefits of the lockstep update policy, not Treble in general, I grasp that.)

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#225

Post by zepto »

angryasian wrote: post #223
zepto wrote: post #51

Earlier quoted context omitted.

Apple doesn’t have a monopoly on Apple silicon nobody buys it.

>the exclusive possession or control of the supply of or trade in a commodity or service. They have exclusive possession or control of supply of these types of chips. I'm not sure if the question of whether or not they could sell or want to sell it comes into question. Lets say I buy up all the supplies of diamonds and exclude the use of diamonds in any other use than my jewelry. I believe this still falls under a mo…

There is no analogy with diamonds, because Apple doesn’t buy up a supply.

There is no supply to buy up - these are just a part apple has made for their own product.

If you use the logic that parts you make for your own products are ‘monopolies’, then most product companies are monopolies, and the term becomes meaningless.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#226

Post by sitkack »

userbinator wrote: post #96
sitkack wrote: post #29

Time is now for an unencumbered SoC with fully available documentation, 1k+ pages downloadable as a complete set of PDFs along with a reference design.

If you count what's been leaked, Mediatek ones would qualify. 1k pages is underestimating by quite a bit. 3-4k pages is closer to the norm, and that's just most of the programming/registers documentation. The complexity in these SoCs is astonishing.

It was more aspirational, 1k of documentation and -3k of errata that never existed.
Post reply on HN