Google found 300 infected apps

[Sniperfox47]

30 minutes ago, Ryan_Vickers said:

The problem with android and the whole ecosystem though is most people are severely behind on updates, not because they ignore them like they do on windows, but because they just aren't available due to having to go through the maker (Samsung, etc) and then sometimes even the carrier before they get to the device.  On top of that, I think android phones are also generally not supported for as long s they should be... Not as long as iphones.

Oh no. I totally agree with that. I am really really really hoping Treble and RRO/OMS helps with that. If carriers and OEMs don't have to do any work to run the latest AOSP version on their device, there'll be no excuse for them not to offer it.

 

I made the comment about not caring because I've seen a number of tech enthusiasts on this very forum making comments like that, as though they don't realize that those sentiments just contribute to the problem. If we don't pressure the OEMs into providing timely updates, we give them an excuse not to update at all.

 

 

[Shreyas1]

6 hours ago, Ryan_Vickers said:

The problem with android and the whole ecosystem though is most people are severely behind on updates, not because they ignore them like they do on windows, but because they just aren't available due to having to go through the maker (Samsung, etc) and then sometimes even the carrier before they get to the device.  On top of that, I think android phones are also generally not supported for as long s they should be... Not as long as iphones.

I never understood how this works when a company like ms can easily do this with windows 

[vanished]

26 minutes ago, Shreyas1 said:

I never understood how this works when a company like ms can easily do this with windows 

yeah, it's an odd one for sure.  People always compare to apple and say android updates have to reviewed and changed by each maker (Samsung, LG, HTC, etc) where as apple can just push them directly, as can google when it's a nexus/pixel device, but that's not a valid excuse since, as you said, Windows runs on a wide variety of hardware - far more so than there are varieties of phones - and yet we don't need Dell or HP interfering in updates from Microsoft, nor do ISPs plant additional software or disable features of your device.

[Shreyas1]

10 hours ago, SpaceGhostC2C said:

 

Yes, "app stores" have created a false sense of security (maybe the reason people don't download shady stuff so boldly in PC is because they have to go to shady websites to get them in the first place), that gives apps offered there an air of "official" or "approved", when in reality that's beyond unfeasible for the store owners. 

most people just don't think phones can get malware.

 

[ARikozuM]

20 hours ago, Ryan_Vickers said:

I'd be curious to know how many new apps, and updates to existing apps are submitted per day, and what kind of manpower it would take to have experts thoroughly review the entire code for each one before approval.  I assume it would be impractical, but that's the only way to be completely sure they're safe.  inb4 they make an AI for this

Will it start using profanity and Hitler jokes before approval?

[mr moose]

9 hours ago, Ryan_Vickers said:

nor do ISPs plant additional software or disable features of your device.

I reckon they would if they could. 

 

 

Anyway, the only reason google found 300 is because they're not looking hard enough.

[Sniperfox47]

10 hours ago, Ryan_Vickers said:

yeah, it's an odd one for sure.  People always compare to apple and say android updates have to reviewed and changed by each maker (Samsung, LG, HTC, etc) where as apple can just push them directly, as can google when it's a nexus/pixel device, but that's not a valid excuse since, as you said, Windows runs on a wide variety of hardware - far more so than there are varieties of phones - and yet we don't need Dell or HP interfering in updates from Microsoft, nor do ISPs plant additional software or disable features of your device.

It's a little bit of a different market. If you look at Windows phone for example, they had some of the same issues, and that was with a much *much* smaller device base to try and manage, and an established and stable ABI for it's NT kernel. Look at the various Windows Phone 10 builds that didn't come out on certain HP phones for whatever reason.

 

The issue is that, for years before the whole smartphone OS thing was even a thing, carriers in the US had gotten used to this idea of controlling every part of the users device. And with Android, iOS, and even Windows Phone when a new update comes out they feel the need to certify it before it rolls out. They have a lot of pull with regards to hardware manufacturers, especially since the *vast* majority of users buy a device from a retail outlet or direct from carrier.

 

That's only one side of things for Android though. With Windows, you can at least skirt some of the certification issues by using the same drivers, but because Android uses Linux and Linux is Linux, there's no stable ABI for the kernel. It literally changes every kernel version. Which means that you need new certified drivers from the chipset maker for each new version of the OS. And then you need to get the phone recertified with the carrier. And then when they don't like it because of whatever quirk, you have to go back and start all over. And then finally when they like it you can start rolling out the update to your users.

 

So why don't manufacturers just roll it out in other countries and say screw the US? Because devices travel into the US, and the US carriers don't like that.

 

iOS has less problems likewise because they control more of the OS layers. Kernel with stable ABI. Drivers they don't need to update, or can get pre-approved. Less devices to handle updates for.

 

Keep in mind, Apple has less different new devices to update per year than Samsung does,  and Samsung's just one Android phone maker who doesn't even have control over all the aspects of that phone.

[sof006]

I feel like Google should post a list of the apps that it removed so people can remove them from their phones if they have them installed.

[LAwLz]

12 minutes ago, Sniperfox47 said:

-snip-

The lack of updates is not because of certifications, nor is it the fault of it being based on the Linux kernel.

GNU/Linux on x86 have none of these issues.

 

I don't know why updates for phones are so hard to make, but the fact of the matter is that each device needs a custom tailored version. This is true for Android, iOS and Windows Phone devices. For some reason it is not possible to create a generic install version and just install that on multiple different phones.

The underlying issue has nothing to do with certification. Just look at the custom ROM scene if you do not believe me. Do you think Cyanogenmod got each build for each phone approved by all US carriers before they pushed it out? Of course not. But it still took them a very long time to create new versions for phones.

 

12 minutes ago, Sniperfox47 said:

So why don't manufacturers just roll it out in other countries and say screw the US? Because devices travel into the US, and the US carriers don't like that.

Manufactures already does that...

It is very common that other countries gets updates a long time before US devices gets them.

Handset makers do not withhold updates just because US carriers want more control over their networks.

[Sniperfox47]

5 hours ago, LAwLz said:

The lack of updates is not because of certifications, nor is it the fault of it being based on the Linux kernel.

GNU/Linux on x86 have none of these issues.

GNU/Linux on traditional x86 doesn't care because you just recompile the driver for the new kernel. And if the ABI breaks the driver in some way, you just go into the driver and fix it, or use a shim to mask the issue. Think about how often a Akmod breaks from a kernel update, and has to be updated manually. It's not a *ton* but it does happen pretty frequently.

 

On a laptop you can do this because you don't have a carrier in the way. You're not under contract with the carrier for them to sell your laptop in their store. On a mobile the situation is pretty different.

 

Ubuntu touch had all these same issues, and it was GNU/Linux. Their workaround was just to update drivers as little as possible, and handle pretty much everything as app updates on top of a long term support model. If you notice, Google's been moving in this direction with Android too. First they moved more and more apps out of the system and into Play Store and Google Play Services. And now with Treble they're defining a stable ABI to decouple the drivers and kernel from the rest of the OS.

 

5 hours ago, LAwLz said:

I don't know why updates for phones are so hard to make, but the fact of the matter is that each device needs a custom tailored version. This is true for Android, iOS and Windows Phone devices. For some reason it is not possible to create a generic install version and just install that on multiple different phones.

They're not hard to make. Taking AOSP and compiling it for your phone is pretty easy, assuming you have access to drivers and a device tree for your hardware. Even if you don't, it's not typically a ton of work to just rip the ones from the OS, shim it and work out the kinks. It's hacky, but doable.

 

It's absolutely possible to create a single rom with an installer that would work across devices, using device tree. You'd need the rom to have all the drivers for all the displays, chipsets, sensor hubs, storage controllers, GPUs, ect. Then you'd repartition the device to fit all this stuff and risk bricking the device, compile a kernel for the device with Device Tree, build a partition bootable by the devices bootloader, and push everything to the phone.

 

It would be an incredibly wasteful process that would risk destroying the user's phone and wouldn't really save any hassle, but it's possible.

 

The reason why you need so many more low level drivers, as well as a device tree, is simply because you don't have a standardized firmware interface like on PC. Most phones don't have UEFI, AHCI, ACPI, and the like because they'd be costly and space consuming to implement. Most Android tablets don't have this either. If you look at Windows tablets, they specifically do have all these things in order to stay compatible.

 

This doesn't really make compiling the new version any harder, it just makes it more complicated than on PC.

 

6 hours ago, LAwLz said:

The underlying issue has nothing to do with certification. Just look at the custom ROM scene if you do not believe me. Do you think Cyanogenmod got each build for each phone approved by all US carriers before they pushed it out? Of course not. But it still took them a very long time to create new versions for phones.

Because those custom rom makers aren't contractually bound by the carriers. Because they don't really on the carriers to sell their hardware.

 

Custom "AOSP Android N for the Android M phone!" ROMs are all over the place, often waaaaaaaaaaay before the manufacturer gets it pushed out. They're also commonly, at least on less popular devices, pushed out by members who don't have a ton of experience in the ROM scene.

 

When you get talking about Cyanogen, you get talking about major changes to the low level functionality of a massive OS, done by a small and largely community based team, with little to no help from the original OSes makers. Duh it takes a while. There's a reason why a lot of root software has different versions for AOSP+OEM than for Cyanogen, because they make quite substantial changes to the underlying layers.

 

OEMs don't really do that  It's mostly "Fork the latest version, add a bunch of our own software, tweak the SystemUI app a bit, and maybe inject a few features without digging too deep into the internals". With Android N devices this got even more the case, since a lot of what they were doing before could be handled by vendor code and RRO. With Android O, I bet it'll be even more so due to OMS. There's no real reason for OEMs to tweak any underlying Android code anymore, since they can just use OMS to load their own overlays into the system anyways, and update those overlays on the fly through Google Play.

 

6 hours ago, LAwLz said:

Manufactures already does that...

It is very common that other countries gets updates a long time before US devices gets them.

Handset makers do not withhold updates just because US carriers want more control over their networks.

I guess Google and HTC lie on their graph of how Android updates are handled then? And Google, OnePlus, and the old Cyanogen team all lied when discussing issues about why updates get so delayed?

 

Google updates Android.

The AOSP code goes to chipset devs who make new board support packages for the new OS.

They provide these packages to the OEMs who compile AOSP with these packages, as well as their own modifications.

This version of the OS then goes to the partner carriers for testing and approval.

If approved it then goes for Carrier, and Regulatory, and Google CTS certification.

If it passes all of these then, and only then, can the OEM start pushing it out to devices.

[LAwLz]

7 minutes ago, Sniperfox47 said:

GNU/Linux on traditional x86 doesn't care because you just recompile the driver for the new kernel. And if the ABI breaks the driver in some way, you just go into the driver and fix it, or use a shim to mask the issue. Think about how often a Akmod breaks from a kernel update, and has to be updated manually. It's not a *ton* but it does happen pretty frequently.

2

I think it has more to do with the fact that ARM devices (not just Android, but iOS and Windows Phone) seem to lack standardized buses which would allow for simple PnP driver models to work.

I am by no means a skilled programmer, but I have looked through the code for some ROMs like Cyanogenmod, and all of them contains unique configuration which is custom tailored for the specific devices they are meant to be installed on.

 

9 minutes ago, Sniperfox47 said:

On a laptop you can do this because you don't have a carrier in the way. You're not under contract with the carrier for them to sell your laptop in their store. On a mobile the situation is pretty different.

Except it isn't a different situation on mobile. The US is one of the very few countries who have carriers modifying phones. In most countries, selling a laptop is exactly the same as selling a cellphone. Neither the carriers nor store do any modifications whatsoever to the devices. Again, it is not rare that phones outside of the US get updates long before the US version does, just because other countries don't have carriers modifying things.

 

27 minutes ago, Sniperfox47 said:

They're not hard to make. Taking AOSP and compiling it for your phone is pretty easy, assuming you have access to drivers and a device tree for your hardware. Even if you don't, it's not typically a ton of work to just rip the ones from the OS, shim it and work out the kinks. It's hacky, but doable.

If that's the case then why does it often take a pretty long time for custom ROMs to get developed (and even longer for them to become stable and functioning)?

The source code for Android O has been out for over a week now, and yet I am not aware of any Android O based ROMs existing for the Galaxy S8 for example. I am not sure if third party Android O ROMs exist for any device right now.

Hell, if it was as easy as you said then you'd think that a ROM like Lineage OS would not have a tremendous amount of issues, which differs from device to device.

 

 

35 minutes ago, Sniperfox47 said:

The reason why you need so many more low level drivers, as well as a device tree, is simply because you don't have a standardized firmware interface like on PC. Most phones don't have UEFI, AHCI, ACPI, and the like because they'd be costly and space consuming to implement. Most Android tablets don't have this either. If you look at Windows tablets, they specifically do have all these things in order to stay compatible.

This I 100% agree with, and I think that is a much more logical explanation for why it takes a long time to develop updates (not just for Android, but iOS and Windows Mobile as well), instead of "it's carriers that are at fault!" because that argument does not hold water outside of the US.

 

 

37 minutes ago, Sniperfox47 said:

This doesn't really make compiling the new version any harder, it just makes it more complicated than on PC.

"It doesn't make it harder, just more complicated".

Ehm... What? If it's more complicated then it is harder.

 

 

39 minutes ago, Sniperfox47 said:

I guess Google and HTC lie on their graph of how Android updates are handled then? And Google, OnePlus, and the old Cyanogen team all lied when discussing issues about why updates get so delayed?

I think a better explanation is that you have just misread things. In fact, the HTC graph explicitly shows that carrier devices go through more verification/certification steps than unlocked devices.

Manufacturers like HTC do not withhold updates for unlocked devices just because US carriers want to run their own tests. This was extremely obvious if you were following the Verizon Galaxy Nexus update history.

The "carrier devices" part of HTC's graph basically only applies to America, because your carriers are assholes. Here in Sweden (and many, if not all other countries) carriers do not touch devices. There is no such thing like verifying the phone for the network (hello GSM, thanks for being awesome) nor do they change anything about the OS on phones.

 

 

45 minutes ago, Sniperfox47 said:

Google updates Android.

The AOSP code goes to chipset devs who make new board support packages for the new OS.

They provide these packages to the OEMs who compile AOSP with these packages, as well as their own modifications.

This version of the OS then goes to the partner carriers for testing and approval.

If approved it then goes for Carrier, and Regulatory, and Google CTS certification.

If it passes all of these then, and only then, can the OEM start pushing it out to devices.

 

That only applies to countries with asshole carriers like the US.

You can completely remove the part about carriers having any say in updates when talking about countries like Sweden. Again, check HTC's graph if you don't believe me. Step 7 and 8 on the orange line (HTC working with carriers to define and implement carrier modifications) simply don't exist for the unlocked phones.

US carriers add 3 additional steps (according to HTC) for releasing an update, and HTC will not just sit on their ass and wait for those additional steps to be done before releasing an update. Oh no, they will release it to countries who don't have fucked up carriers as soon as they can. Again, that's why a lot of countries gets updates way before the US does.

[Sniperfox47]

39 minutes ago, LAwLz said:

I think it has more to do with the fact that ARM devices (not just Android, but iOS and Windows Phone) seem to lack standardized buses which would allow for simple PnP driver models to work.

I am by no means a skilled programmer, but I have looked through the code for some ROMs like Cyanogenmod, and all of them contains unique configuration which is custom tailored for the specific devices they are meant to be installed on.

They do have standardized "busses". M-Phy and USB are the most common. And then emmc or ufs for storage. And the reason why I quoted busses is because technically they're not all busses, some are point-to-point interconnects just like PCIe.

 

Yeah, that's part of device tree. It's a linux setup that outlines how busses are connected, and how they're communicated with/mapped to DMI. It basically replaces all the low level mapping that UEFI does for you with POST. There's also sometimes special modifications for devices because of firmware or driver bugs, as well as for mapping how partitions are laid out since you don't want to reformat these devices.

 

39 minutes ago, LAwLz said:

Except it isn't a different situation on mobile. The US is one of the very few countries who have carriers modifying phones. In most countries, selling a laptop is exactly the same as selling a cellphone. Neither the carriers nor store do any modifications whatsoever to the devices. Again, it is not rare that phones outside of the US get updates long before the US version does, just because other countries don't have carriers modifying things.

It's not about them modifying things though. Even phones without carrier modifications still need to be carrier ratified to ensure compliance. It's no different than if you make an RC car you need to get it RF certified before you can sell it, to ensure it won't cause interference. With phones, carriers -particularly US carriers- get a bit overzealous in their quest to make sure every device is compliant with their standards. In a perfect world all radio chipset makers would make chipsets and drivers that perfectly comply with LTE specs, and the OS would never interfere with these drivers or cause them to hang or do inappropriate things. That's not the world that we live in though. And although it doesn't really matter that stuff happens sometimes, it doesn't stop regulators and carriers from freaking out about it.

 

39 minutes ago, LAwLz said:

If that's the case then why does it often take a pretty long time for custom ROMs to get developed (and even longer for them to become stable and functioning)?

The source code for Android O has been out for over a week now, and yet I am not aware of any Android O based ROMs existing for the Galaxy S8 for example. I am not sure if third party Android O ROMs exist for any device right now.

Hell, if it was as easy as you said then you'd think that a ROM like Lineage OS would not have a tremendous amount of issues, which differs from device to device.

 

Because the S8 has no published drivers for O... or device tree... and has a locked bootloader... and has Knox which is a PITA to work around without proper keys from Samsung?

 

On the Nexus 5 which has everything you need there's already one: https://www.androidheadlines.com/2017/08/highly-unstable-early-android-8-0-oreo-rom-hits-nexus-5.html

 

And why does it take so long to get them stable? Because manufacturers don't have a consistent kernel, which means they have different drivers, which may interact poorly with the kernel you build based on which security patches your kernel may or may not provide, and which other modules it may or may not load. And those differences could break drivers, which could in turn cause issues. And without an official device tree, you may miss a detail. Or the manufacturer may know there's a bug in a given driver and have had a shim to workaround it that you don't have. And usually you don't have a driver for their sensor hub, so you're left hacking and guessing at it yourself... Like that Nexus 5 one will probably never be stable, because there's no support package from qualcomm for newer versions of Android for that chipset... So it's going to be a matter of hacking things together to get all the existing drivers working.

 

39 minutes ago, LAwLz said:

"It doesn't make it harder, just more complicated".

Ehm... What? If it's more complicated then it is harder.

open terminal and typing "sudo make install" is more complicated than click click click on an installer. It's not any harder if you know what you're doing. That's the difference I meant. Having device tree and other complications sits in the background and doesn't really affect the work you need to do.

 

39 minutes ago, LAwLz said:

I think a better explanation is that you have just misread things. In fact, the HTC graph explicitly shows that carrier devices go through more verification/certification steps than unlocked devices.

Manufacturers like HTC do not withhold updates for unlocked devices just because US carriers want to run their own tests. This was extremely obvious if you were following the Verizon Galaxy Nexus update history.

The "carrier devices" part of HTC's graph basically only applies to America, because your carriers are assholes. Here in Sweden (and many, if not all other countries) carriers do not touch devices. There is no such thing like verifying the phone for the network (hello GSM, thanks for being awesome) nor do they change anything about the OS on phones.

I'm not from America so I'm not sure where you get that impression

 

I never said that the carrier modification part applies to all phones, I said that it applies with carrier partners.

 

The carrier certification part at the bottom of that HTC graph, as well as regulatory certification beside it does apply to all three. Notice the big black box around all three that all paths lead into?

 

We use entirely GSM networks in Canada too. There are still issues that come up with noncompliant devices though. Like emergency services not functioning because the radio of certain Android M phones didn't support a feature even though they claim to.

 

I'm not talking about carrier specific CDMA phones like with Verizon... I'm talking about unlocked and carrier locked GSM phones.

 

42 minutes ago, LAwLz said:

That only applies to countries with asshole carriers like the US.

You can completely remove the part about carriers having any say in updates when talking about countries like Sweden. Again, check HTC's graph if you don't believe me. Step 7 and 8 on the orange line (HTC working with carriers to define and implement carrier modifications) simply don't exist for the unlocked phones.

US carriers add 3 additional steps (according to HTC) for releasing an update, and HTC will not just sit on their ass and wait for those additional steps to be done before releasing an update. Oh no, they will release it to countries who don't have fucked up carriers as soon as they can. Again, that's why a lot of countries gets updates way before the US does.

You're ignoring keywords... Carrier partners... In the case of an unlocked phone a carrier partner is nobody.  In the case of a locked phone sold through a carrier a carrier makes no modifications, and typically doesn't test the phone. The EU *does* have an RF regulatory commission though, and a carrier industry group that *DO* do radio certifications on the device, which is what the carrier certification and regulatory certification at the bottom are. 

 

 

 

 

 

[Doobeedoo]

Good, purge infectious!

[LAwLz]

34 minutes ago, Sniperfox47 said:

They do have standardized "busses". M-Phy and USB are the most common. And then emmc or ufs for storage. And the reason why I quoted busses is because technically they're not all busses, some are point-to-point interconnects just like PCIe.

That's not anywhere near the same level of standardization and "PnP" design as x86 computers have though.

 

37 minutes ago, Sniperfox47 said:

It's not about them modifying things though. Even phones without carrier modifications still need to be carrier ratified to ensure compliance. It's no different than if you make an RC car you need to get it RF certified before you can sell it, to ensure it won't cause interference. With phones, carriers -particularly US carriers- get a bit overzealous in their quest to make sure every device is compliant with their standards. In a perfect world all radio chipset makers would make chipsets and drivers that perfectly comply with LTE specs, and the OS would never interfere with these drivers or cause them to hang or do inappropriate things. That's not the world that we live in though. And although it doesn't really matter that stuff happens sometimes, it doesn't stop regulators and carriers from freaking out about it.

1

The way things are handled in EU and America are completely different.

Again, not sure how many times I need to tell you this but in most countries, the carriers do not make any modifications to the OS. None. They do not go in and check the code, or request changes for their particular network.

Because of the brilliant standard that is GSM, all the carrier needs to do to ensure compatibility is push out some simple text strings such as APN, MCC and MNC and the handset will be able to connect to the network just fine.

I can not find any evidence that each update for phones needs to pass tests in Europe. Neither from carriers nor from a notified body that can do CE marking tests.

 

A European carrier will not say "this phone is not allowed to connect to our network unless you do these modifications". I am not even sure if there exists a mechanic for them to do such a thing.

 

 

1 hour ago, Sniperfox47 said:

Because the S8 has no published drivers for O... or device tree... and has a locked bootloader... and has Knox which is a PITA to work around without proper keys from Samsung?

 

On the Nexus 5 which has everything you need there's already one: https://www.androidheadlines.com/2017/08/highly-unstable-early-android-8-0-oreo-rom-hits-nexus-5.html

 

And why does it take so long to get them stable? Because manufacturers don't have a consistent kernel, which means they have different drivers, which may interact poorly with the kernel you build based on which security patches your kernel may or may not provide, and which other modules it may or may not load. And those differences could break drivers, which could in turn cause issues. And without an official device tree, you may miss a detail. Or the manufacturer may know there's a bug in a given driver and have had a shim to workaround it that you don't have. And usually you don't have a driver for their sensor hub, so you're left hacking and guessing at it yourself... Like that Nexus 5 one will probably never be stable, because there's no support package from qualcomm for newer versions of Android for that chipset... So it's going to be a matter of hacking things together to get all the existing drivers working.

So what you're saying is that your previous post was very much an oversimplification and the reality is that you can't just take AOSP, rip the device tree and drivers from the OS and then compile it. You know, like you said you could do easily in your previous post.

It's almost as if you need to make quite substantial modifications to make things work on each individual device...

This is the case with Windows Mobile as well by the way. It's not something specific to Android or GNU/Linux. If it was then Windows Mobile would not have such awful support, with plenty of phones not getting the same updates as other phones.

 

 

1 hour ago, Sniperfox47 said:

I never said that the carrier modification part applies to all phones, I said that it applies with carrier partners.

What do you define as a carrier partner?

Because you said this before, which heavily implies that US carriers will prevent European phones from getting updates until the updates are ready for the US market too:

9 hours ago, Sniperfox47 said:

So why don't manufacturers just roll it out in other countries and say screw the US? Because devices travel into the US, and the US carriers don't like that.

 

 

1 hour ago, Sniperfox47 said:

We use entirely GSM networks in Canada too. There are still issues that come up with noncompliant devices though. Like emergency services not functioning because the radio of certain Android M phones didn't support a feature even though they claim to.

Congratulations. You just posted evidence that carriers do not do testing on phones the same way they are in the US.

I mean, if they don't even test if emergency calls work on phones then I kind of doubt they do any tests to ensure things such as network compatibility.

 

 

1 hour ago, Sniperfox47 said:

You're ignoring keywords... Carrier partners...

I did not ignore anything. You have only mentioned "carrier partners" in one post and that's this one. As far as I am aware, "carrier partner" is an entirely made up term as well, so I have no idea what it actually means.

 

1 hour ago, Sniperfox47 said:

In the case of an unlocked phone a carrier partner is nobody.  In the case of a locked phone sold through a carrier a carrier makes no modifications, and typically doesn't test the phone. The EU *does* have an RF regulatory commission though, and a carrier industry group that *DO* do radio certifications on the device, which is what the carrier certification and regulatory certification at the bottom are. 

 

And that's NOTHING like the things US carriers do when they test and request things from handset makers for use in their network. 

Handsets gets verified for CE markings in EU, and as far as I know and can tell that only happens once, not for each update. That's it.

In the US every update has to be negotiated between the manufacturer and carrier to determine which things will be included in the update, and what needs to get changed, for example removing mobile hotspot support, bundling apps and so on.

 

 

Just so that we are clear. I disagree with three points in your post.

1) That it is a Linux issue that Android devices don't get updates. While Linux has some issues you have brought up, updates being difficult to make is not a problem unique to Linux based phones. iOS and Windows Phone/Mobile suffers from it too. Wouldn't be surprised if other mobile OSes have similar issues too.

At the end of the day, OSes and OS updates need to be much more device specific than updates for let's say an x86 desktop.

 

2) That making an update for Android is easy. Even in your own oversimplified explanation you needed to add a lot of "then you need to write a shim, and you need this, and then you need that, and you need to update the drivers..."

 

3) That manufacturers withhold updates for the rest of the world because US carriers want to do their own tests. Samsung does not give two shits about what tests Verizon wants to do before deploying the update. Samsung won't just sit there for weeks or months with an update ready to be deployed in Korean just because a US carrier wants to do tests on their network. They will release the update in Korean regardless of whether or not the US carrier is satisfied.

Again, Samsung will not withhold an update for a Swedish phone just because a US carrier wants to bundle some extra apps.

This is the reason why the rest of the world usually gets updates weeks or months before the US does. Because we can skip the bullshit things carriers in the US pulls.

 

 

Those are the 3 things I disagree with. Nothing more and nothing less.

Now if I have misinterepeted some of your posts then please explain what you actually meant. That's how I have interpeted your posts so far though, and I will respond as if that's what you meant.

[Sniperfox47]

6 hours ago, LAwLz said:

~snip~

I'm not going to go through things point by point at this end because it's getting ridiculous, sorry. I'll just comment on your arguments as a whole again.

 

You're conflating my arguments and manipulating my arguments to fit your narrative.

 

1) The number of differences to the driver layer on a Linux based phone like Android, Meego, Ubuntu Touch and others are *substantially* more than on NT and Mach based devices.

 

Did Windows Phone have similar issues? Absofreakinglutely. I said as such myself above. Were they anywhere near as severe? Not in the slightest. Nokia rolled out pretty much every Windows 10 build on pretty much every device that was still covered within weeks. Even HP was pretty good about keeping up.

 

2) You're conflating user level ROM scene development with actual OEM device development. These are far *far* different things. Users don't have access to the same support packages that OEMs do. In case you didn't notice, above I specifically said that for everything to work smoothly you need updated Board support packages with updated drivers and shims which users almost never have.

 

You can make a rom by ripping everything pretty easy. Does that make it a stable ROM? No. I never said it did. You're ripping and hacking stuff, why would you imagine it's stable? OEMs don't have this issue. They have the issue of waiting for updated Board Support packages.

 

This is, primarily, a Linux issue. Do you need chipset maker support to make a NT based Phone? Yeah, that's why you can't get indefinite updates on Windows Phone. Do you need anywhere near the same level of support as for a Linux based phone?

 

This step is part of what Treble is cutting out. Manufacturers no longer need to play this waiting game. It also cuts out a lot of the carrier and regulatory certification process. This will leave only the actual work of porting, (which should take maybe a month or two rather than 8-12) and the issues with US carriers.

 

3) They absolutely do. The US has *huge* market power and control. After China and India they are the single biggest market. Are they super dense? Not even close. But they're a bigger market than most of Europe combined. The whole of the EU is only 1+1/2 the population of the US, and *isn't* a cohesive whole for OEMs to roll out their devices to.

 

Samsung doesn't have a "Korean" s8 though... They have an international s8 that's deployed everywhere. And needs to be checked for regulatory compliance everywhere.And needs to be checked for carrier compliance everywhere. Because if they roll out the update to a device that wasn't sold in Korea and used by a person in Korea before getting compliance certification, they'd be opening themselves up to legal nightmares.

 

Those two issues are distinct though. Carriers being entitled to test every phone for their networks (carrier certification) and US carriers gucking things up are completely seperate issues. You keep talking about how in the EU carriers don't touch and check the phones for their networks, but they absolutely do, just not directly like CDMA networks on the states. They do so like they do in Canada and most of the rest of the world, which is through a carrier industry group that tests and certifies the devices against reference equipment.

 

Treble makes carrier certification less of an issue, it does not make US carriers less of an issue.

[LAwLz]

2 hours ago, Sniperfox47 said:

1) The number of differences to the driver layer on a Linux based phone like Android, Meego, Ubuntu Touch and others are *substantially* more than on NT and Mach based devices.

 

Did Windows Phone have similar issues? Absofreakinglutely. I said as such myself above. Were they anywhere near as severe? Not in the slightest. Nokia rolled out pretty much every Windows 10 build on pretty much every device that was still covered within weeks. Even HP was pretty good about keeping up.

2

Source? They might have been able to rollout updates quickly because they were owned and worked very closely with Microsoft. I have not been following Windows phone handset updates from third parties that closely so I can't comment on how fast/slow Samsung, HTC, ZTE or other manufacturers were with updates.

 

2 hours ago, Sniperfox47 said:

2) You're conflating user level ROM scene development with actual OEM device development. These are far *far* different things. Users don't have access to the same support packages that OEMs do. In case you didn't notice, above I specifically said that for everything to work smoothly you need updated Board support packages with updated drivers and shims which users almost never have.

 

You can make a rom by ripping everything pretty easy. Does that make it a stable ROM? No. I never said it did. You're ripping and hacking stuff, why would you imagine it's stable? OEMs don't have this issue. They have the issue of waiting for updated Board Support packages.

 

This is, primarily, a Linux issue. Do you need chipset maker support to make a NT based Phone? Yeah, that's why you can't get indefinite updates on Windows Phone. Do you need anywhere near the same level of support as for a Linux based phone?

 

This step is part of what Treble is cutting out. Manufacturers no longer need to play this waiting game. It also cuts out a lot of the carrier and regulatory certification process. This will leave only the actual work of porting, (which should take maybe a month or two rather than 8-12) and the issues with US carriers.

Are you being misleading on purpose?

"It's easy to make a ROM!"

"Oh, I never said it was easy to make a ROM that's actually usable! Did you actually think I was talking about making something that works?"

Come the fuck on... This is getting silly.

 

Also, are you seriously saying that an OEM such as Samsung only spends about 1-2 months developing an update, and then have to wait up to 12 months for certification to be done? [Citation Needed]

I do not believe that it is that fast to create the update, and then that slow to get it verified to use.

 

2 hours ago, Sniperfox47 said:

3) They absolutely do. The US has *huge* market power and control. After China and India they are the single biggest market. Are they super dense? Not even close. But they're a bigger market than most of Europe combined. The whole of the EU is only 1+1/2 the population of the US, and *isn't* a cohesive whole for OEMs to roll out their devices to.

 

Those two issues are distinct though. Carriers being entitled to test every phone for their networks (carrier certification) and US carriers gucking things up are completely seperate issues. You keep talking about how in the EU carriers don't touch and check the phones for their networks, but they absolutely do, just not directly like CDMA networks on the states. They do so like they do in Canada and most of the rest of the world, which is through a carrier industry group that tests and certifies the devices against reference equipment.

5

[Citation Needed]

I do not believe for one second that a US carrier have blocked an update in Sweden because "we haven't checked it on our network yet".

In fact, I can not find any evidence whatsoever that each individual update gets tested by carriers in countries other than the US. If anything, the things you have posted such as marshmallow breaking emergency calls would indicate that updates are NOT getting checked. On top of that, updates usually get released far quicker in for example Sweden than in the US.

I can't find anything about needing to retest for CE markings either. Seems to be tested once and then you're good to go.

 

Samsung releases monthy updates for some of their phones. Does each and every update have to be tested by every single carrier and/or other certification organization? I don't think so.

 

And like I said before (since I feel like you will accuse me of strawmanning):

9 hours ago, LAwLz said:

Now if I have misinterepeted some of your posts then please explain what you actually meant. That's how I have interpeted your posts so far though, and I will respond as if that's what you meant.