Forum Discussion
OnePlus 8 Android 12
Ok I'm about done hearing that the Unlocked variants OnePlus 8 and 8 Pro are on Stable versions of android 12 while being stuck with the carrier variant means we probably won't see Android 12 on T-Mo...
Makulund wrote:
Ok I'm about done hearing that the Unlocked variants OnePlus 8 and 8 Pro are on Stable versions of android 12 while being stuck with the carrier variant means we probably won't see Android 12 on T-Mobiles OnePlus 8 or 8 Pro until Android 13 drops this is ridiculous thanks T-Mobile!
unlike popular belief… Carriers have little control, and don't touch the code like people think they do. Multiple times OEM(manufacturers) have admitted it, but here in the states we still blame carriers. Ever noticed Google doesn't blame carriers anymore after about a year of them complaining? Why? They did an AOSP project with Sony and found out that carriers DON'T actually delay updates no more than a month in 90% of cases. They only time there is any lengthy delay is where a security flaw was found.
Other OEM's have pushed out their updates on T-Mobile except OnePlus. They chose to update process for T-Mobile. Why would T-Mobile delay 1 manufacturer over all the others they have? Think about it for a second. IF you device is paid off you can actually load the OnePlus version and run it instead of waiting for a T-Mobile version coming out. OnePlus forums will show you how to do it.
foobar wrote:Carriers definitely play a role in delays.
Carriers have little to no direct control in the development of the updates. However, they're the ones that put the requirements in place of which customizations/settings, extra apps, telemetry, restrictions, testing, etc, that the oems have to develop and implement, and the more they add or require, the longer you can expect the updates to take. If they didn't have additional requirements, it'd just be the unlocked version and there's be little delay (save time for testing/verification). So while they have little control, their extra requirements can still be a significant source of delays imo.
As examples of extra value that carriers require oems implement - potentially contributing to delays, look at things like Digital Turbine Ignite and SingleTap that allow bloatware and apps to be installed bypassing Google Play.
It's already been pointed out since early life of Android. Even Google believed it UNTIL they actually did their own case study with Sony during an AOSP project. They found out carriers has very little to do with delays if any at all. HTC, Sony, Motorola, and Samsung rolled out timelines of how things are done, and quite a few of their development team managers have pointed this out as well. It's one of the reasons why if you go to other carrier forums in other countries they blame OEM's yet we blame carriers. Try buying a Samsung phone directly from Korea, and talk about bloat and carrier customizations and how does Samsung release that version first before US carriers? Oh I used to work for Samsung Korea for reference. Currently working for the DoD doing software.
Customization being a delay is the BIGGEST lie ever told. All carriers AROUND the world has these "customizations". Explain how carriers here are delaying months to years, but the rest of the developed world don't? They are all the same telemetry companies and ran by the same development companies around the world. custom apps for example are done in house and are updated through the app store and very little testing is needed as it can be done in house, and not part of the development process. See Google/Sony AOSP project. To make it FURTHER easier for this they made a carrier partition with specific APIs and can run on older software without carrier intervention. How can Apple do this worldwide and release 1 OS for every carrier if they need all these customizations? I have yet to see an app from any carrier that requires development with OS development to cause a delay.
Examples of SingleTap and Digital Turbine is a very poor example. If they are going to sideload the software only needs to be tested on a VM than actually through development. As a developer standpoint it make 0 sense to develop something you are going to sideload after the fact. As pointed they could just not develop at all and leave it in the carrier partition and it'll run correctly and has the permissions to do so. If Google changed the permissions it's a couple lines of code and viola still doesn't need testing. The only time this wouldn't work is IF OEM's changed how the carrier partitions works, but this could break project treble which is a violation of using Android with Google services.
There's a reason why Google releases a fully developed Kernel months in advance unless like previous versions of Android. Governmental involved has always been the largest delay for software updates. FCC, WiFi, Bluetooth, USB, Qualcomm(especially with CDMA), and a slew of other consortiums, All of these have varying laws and regulations which is the reason why OS versions were all over the place especially during Android infancy. Now you can finish the kernel test it out and see if everything works. You can then develop the OS around that without tweaking the kernel from that point. This is leagues better waiting for the kernel and OS to come and then do the kernel and OS at the same time. More things to go wrong with testing as OS and kernel will have to rewritten.
