Nvidia Says Android Needs a Version of WHQL

[InvalidError]

[citation][nom]balister[/nom]If the resolutions followed a specific format, then a lot of the problems SmugMug's CEO mentioned would go away as it would simply be the system scaling the app to the resolution at hand if it followed something like 4:3 or 16:9.[/citation]
If your application breaks due to aspect ratio, blame your app's developers, not the hardware or drivers - unless the hardware/drivers themselves are crashing specifically due to aspect ratio, which is very unlikely. Windows/Linux software works perfectly fine and aspect ratios on PCs are completely wacky with multi-display arrangements featuring mismatched resolutions, aspect ratios and possibly even display orientation.

I have been using dual-display with a pair of VGA cards since Windows95 and do not remember running across programs that had issues with my extended desktop apart from VGA overlays that obviously cannot span across screens/adapters.

As for Win95's stability, SR1 was a huge improvement over the initial release and I remember being quite happy with it. Then I tried Win98, was crashy as hell so I reverted to Win95OSR1 until Win98SE which was great - at least when compared to Win95/98 original releases. Considering the large amounts of OS-side patching required to bring up Win95/98 reliability, I have strong suspicion that Microsoft earned (caused) its fair share of crashes too.

 

[blazorthon]

[citation][nom]ddpruitt[/nom]Nvidia is right. Fragmentation is horrible on Android. If you don't think so see how many different versions of CyanogenMod there are for such few devices. On the other hand you don't want to limit the inherent innovation available in such an open system. Perhaps the best idea is to standardize on a limited set of hardware so all you need is a single generic driver.[/citation]

Well, there is a middle ground that could easily solve all of the cons without sacrificing the pros. Perhaps most importantly, Google could regulate the quality control of their partners more diligently, at least as far as compatibility goes. Setting requirements to ensure compatibility can be done without limiting the creative differences for different Android partners to compete with each other.

For example, set requirements for the drivers to support certain code and then set requirements for app makers to adhere to those. The latter part of that can probably even be done automatically by the compilers so that it doesn't hinder development, if necessary. With such a basis in place, the custom UIs and such, although they can be as optimized for their driver/hardware combination as need be and can still support all of the apps designed with this in mind, can also still vary to an extreme so long as compatibility of apps is kept in mind.

Oh, and forcing the Android partners and carriers to at least adhere to some sort of unified update schedule could also help. Just because a phone is old doesn't mean that it should have an old OS. Even Apple has gotten that down better according to what I've read and IDC about the excuse that they have fewer types of smart phones.

Each individual Android partner only has so many phones per generation (especially if we count all Nexus phones as different from the other phones by the partners since they run a nearly pure stock version of Android instead of a highly customized version) and the carriers themselves shouldn't have to worry about much as far as the updates go AFAIK. Customers being unable to update a phone to an at least somewhat current version of the OS without rooting and loading up a ROM that isn't standard for the phone is not a valid way to get customers to upgrade their phones more often IMO.

Many others have also suggested standardizing resolutions and such, but honestly, I find that to be unnecessary so long as the phones compensate for the resolution differences. For example, if I have say a 1280x800 phone, then there's no good reason that a 1280x720 anything can't run on it with black bars like we have with many other devices such as TVs or even something else like that.

Most of what I said doesn't really pertain to drivers and thus a driver WHQL-like system wouldn't solve it AFAIK, but that doesn't mean that this stuff couldn't be helpful. I'm not sure how helpful a WHQL (or AHQL as it may be here) would be, but it'd probably help at least some things (even more than drivers if the idea is applied to more than just drivers, IE to the custom kernel/OS stuff and more), especially in ensuring that the other companies adhere to requirements that Google could set for fixing fragmentation.

 

[Shin-san]

$250 for a hardware testing lab is a steal. If it means that your hardware will run with less crashes, I know a lot of outfits that are more than happy to pay. That's less than 1, maybe 2 days worth of paying someone to test software

 

[tobalaz]

As far as I'm concerned, Nvidia shouldn't be bitching about fragmentation in Android.
Anyone ever hear about Nvidia's once crown jewel the Motorola Atrix?
How about the Viewsonic G Tablet?
Both sport Tegra 2 cpus which are easily powerful enough to run Android 4.xx but Nvidia has closed drivers they're not sharing that keep them locked on Froyo and Gingerbread.
I'm not saying open source everything, but driver binaries downloadable for developers using a base AOSP rom would do wonders to reduce fragmentation.
If EVERY company would release AOSP binaries per hardware to the general public it could pull a lot of heat off of the carriers and manufacturers and bless us users with the latest version of a minimalistic version of Android without bloat so we don't have to wait for the carriers to release a feeble, nerfed, slow OS for phones.
But hey, just me ranting here.

 

[InvalidError]

[citation][nom]blazorthon[/nom]Google could regulate the quality control of their partners more diligently, at least as far as compatibility goes. Setting requirements to ensure compatibility can be done without limiting the creative differences for different Android partners to compete with each other.For example, set requirements for the drivers to support certain code and then set requirements for app makers to adhere to those.[/citation]
Google already does that, it is called the Android API.

Android's essence is not the underlying OS, the hardware or the drivers. It is the Java runtime and Android API. The OS does little more than support the Java runtime.

As long as whoever provides the runtime environment implements the Android API properly through whatever means and methods available and as long as applications use the API properly, Android applications should work even on non-Android devices and OSes. If Blackberry adds the Android API to their devices' JRE, they should be able to run most NDK-free Android applications on top of BB10.

Device manufacturers are entirely responsible for ensuring their device's firmware implement the Android API correctly on a properly working JRE and app writers are entirely responsible for following design guidelines and APIs... or choosing to ignore guidelines and use the NDK.

What makes WHQL possible and meaningful for Windows is that there is only one Windows kernel for everyone and only on x86/x86-64. With Android, manufacturers can run the runtime on top of any CPU and OS they want, they can customize their kernel whichever way they want, they can use whatever custom hardware configuration they want so there is no standard hardware/kernel/drivers/software/CPU configuration to qualify hardware/drivers against. Any one manufacturer-specific change may break any number of other things elsewhere. The only thing Android devices are guaranteed to have in common is a JRE supporting some revision of the Android API.

The reason why WHQL was necessary on Windows is because PCs are user-upgradable and most users lack the knowledge and patience to deal with hardware/driver problems when their upgrades go wrong. On the other hand, smartphones and tablets are non-user-upgradable and generally non-user-serviceable. The final hardware configuration is determined at manufacture and you get whatever kernel/drivers/etc. the manufacturer provides. Since the end-user is usually locked-out from being able to fix any "driver" problems themselves and the manufacturer is the only one who can deal with any problems that may arise anyhow, the manufacturer is entirely responsible for ensuring that its hardware ships with proper support regardless of any sort of WHQL-like efforts.

Certification has very little use when you do it for internal use only... I doubt a Samsung-certified kernel module for a custom Samsung kernel for a particular stepping of a given SoC would hold much value for LG who has their own customized kernel targeted for a different SoC.

Non-transferable certification simply makes no sense.

Google would have to forbid OEMs from modifying the reference Android kernel to ensure every driver gets paired with a standardized kernel against which they were certified for such an effort to have even a remote chance of working out but since the Android kernel is based on the GPL'd Linux kernel, this is unenforceable - whatever certification was done gets invalidated the moment manufacturers build their own product-specific kernels and firmware images.

 

[back_by_demand]

[citation][nom]jhansonxi[/nom]Developing a driver that can cross-compile between different architectures isn't easy.[/citation]
So because its difficult we shouldn't do it, then ruthlessly deride the company that suggested it?

 

[Comrade Dope]

Wow, what a shock. Nvidia doesn't understand the concept of Open Source.

You want standards between modders? Then get together and lay 'em out.

You want standards for your hardware...i.e. what a manufacturer can do to Android before your hardware doesn't like it...do so.

Of course the REAL problem for Nvidia is that THEY don't want to Open Source THEIR stuff, so that others can fix it to meet their needs....

Touch being a Copywrong Monopolist in an Open Source world.

 

[back_by_demand]

[citation][nom]Comrade Dope[/nom]Wow, what a shock. Nvidia doesn't understand the concept of Open Source. You want standards between modders? Then get together and lay 'em out.You want standards for your hardware...i.e. what a manufacturer can do to Android before your hardware doesn't like it...do s😵f course the REAL problem for Nvidia is that THEY don't want to Open Source THEIR stuff, so that others can fix it to meet their needs....Touch being a Copywrong Monopolist in an Open Source world.[/citation]
Problem with that is Android isn't as Open Source as you think, sure Linux is but Android's open-source credentials are laughable
...
http://www.pcworld.com/article/246140/is_android_open_not_so_much_study_finds.html
...
It's not nVidia that don't understand the meaning of Open Source, seems more like Google doesn't get it
...
Hating on someone who dares to suggest quality standards for all will only result in one thing - lower quality for everyone

 

[InvalidError]

[citation][nom]back_by_demand[/nom]Problem with that is Android isn't as Open Source as you think, sure Linux is but Android's open-source credentials are laughable.[/citation]
I personally see nothing wrong with it. The source code base is indeed open, albeit under private control.

Most other open-source projects are lead by non-profit organizations, volunteers and developer communities who have no private agenda and need community support to survive. Android on the other hand is backed directly by Google who has bottomless pockets to accommodate Android development expenses using mostly their own paid staff.

Android is effectively an open-access private project.

 

[blazorthon]

[citation][nom]blazorthon[/nom]Google could regulate the quality control of their partners more diligently, at least as far as compatibility goes. Setting requirements to ensure compatibility can be done without limiting the creative differences for different Android partners to compete with each other.For example, set requirements for the drivers to support certain code and then set requirements for app makers to adhere to those.[/citation]
Google already does that, it is called the Android API.

Android's essence is not the underlying OS, the hardware or the drivers. It is the Java runtime and Android API. The OS does little more than support the Java runtime.

As long as whoever provides the runtime environment implements the Android API properly through whatever means and methods available and as long as applications use the API properly, Android applications should work even on non-Android devices and OSes. If Blackberry adds the Android API to their devices' JRE, they should be able to run most NDK-free Android applications on top of BB10.

Device manufacturers are entirely responsible for ensuring their device's firmware implement the Android API correctly on a properly working JRE and app writers are entirely responsible for following design guidelines and APIs... or choosing to ignore guidelines and use the NDK.

What makes WHQL possible and meaningful for Windows is that there is only one Windows kernel for everyone and only on x86/x86-64. With Android, manufacturers can run the runtime on top of any CPU and OS they want, they can customize their kernel whichever way they want, they can use whatever custom hardware configuration they want so there is no standard hardware/kernel/drivers/software/CPU configuration to qualify hardware/drivers against. Any one manufacturer-specific change may break any number of other things elsewhere. The only thing Android devices are guaranteed to have in common is a JRE supporting some revision of the Android API.

The reason why WHQL was necessary on Windows is because PCs are user-upgradable and most users lack the knowledge and patience to deal with hardware/driver problems when their upgrades go wrong. On the other hand, smartphones and tablets are non-user-upgradable and generally non-user-serviceable. The final hardware configuration is determined at manufacture and you get whatever kernel/drivers/etc. the manufacturer provides. Since the end-user is usually locked-out from being able to fix any "driver" problems themselves and the manufacturer is the only one who can deal with any problems that may arise anyhow, the manufacturer is entirely responsible for ensuring that its hardware ships with proper support regardless of any sort of WHQL-like efforts.

Certification has very little use when you do it for internal use only... I doubt a Samsung-certified kernel module for a custom Samsung kernel for a particular stepping of a given SoC would hold much value for LG who has their own customized kernel targeted for a different SoC.

Non-transferable certification simply makes no sense.

Google would have to forbid OEMs from modifying the reference Android kernel to ensure every driver gets paired with a standardized kernel against which they were certified for such an effort to have even a remote chance of working out but since the Android kernel is based on the GPL'd Linux kernel, this is unenforceable - whatever certification was done gets invalidated the moment manufacturers build their own product-specific kernels and firmware images.

That there are still occasional compatibility problems, no matter the cause, shows that Google or at least someone else is not doing enough. Whether or not they do something when what they do is not enough doesn't justify that it isn't enough.

I already understand the reasoning behind WHQL and why an exact same thing won't solve many, if any at all, Android problems. My point was that a similar concept applied to more than just drivers (which I explicitly stated) could help.

Having different certifications between each of the companies is not at all what I was saying. My point was that there should be plenty of room for heavy customization without the need to break compatibility. So, no, there wouldn't need to be any forbidding customization. There would simply need to be a set of compatibility requirements that all customization would need to adhere to and that doesn't need to get in the way of customization in order to work.

GPL in no way stops Google from telling people what they can and can not do with Android to be officially called Android. I can customize it any way that I want (within legal reason), but if Google tells me that I can't call it Android because something I do with it hurts compatibility with official Android apps, then I can't call it Android, nor should I expect to be able to.

Certification merely needs that any Android phone mustn't break compatibility with Android apps. That's not even a particularly difficult thing to do even with custom product-specific kernels and firmware images considered.

 

[blazorthon]

Wow, what a shock. Nvidia doesn't understand the concept of Open Source.

You want standards between modders? Then get together and lay 'em out.

You want standards for your hardware...i.e. what a manufacturer can do to Android before your hardware doesn't like it...do so.

Of course the REAL problem for Nvidia is that THEY don't want to Open Source THEIR stuff, so that others can fix it to meet their needs....

Touch being a Copywrong Monopolist in an Open Source world.

Whether or not something is open source in no way affects whether or not it should work properly and should be able to be expected to work properly.

Whether or not Nvidia makes their stuff more open is also not the point here because that's not really important in this case (it's a bit more of a big deal for the more conventional Linux systems, but even that is debatable). The point here is that Android fragmentation is an issue and it shouldn't be, so it should be addressed and solved.

 

[InvalidError]

[citation][nom]blazorthon[/nom]My point was that a similar concept applied to more than just drivers (which I explicitly stated) could help.[/citation]
And Google has two conformance/validation prerequisites that are intended to do exactly that before manufacturers can request permission to slap the Android label on products.

Even Windows with all its WHQL goodness still has the occasional software/driver/library/COM/etc. that breaks other stuff and the drivers are not necessarily hardware, they can be virtual devices or stuff that installs hooks in the OS to perform or trigger some arbitrary function. At the end of the day though, the main motivation behind WHQL is that drivers on PCs are user-installable.

 

[back_by_demand]

[citation][nom]InvalidError[/nom]At the end of the day though, the main motivation behind WHQL is that drivers on PCs are user-installable.[/citation]
So ... nothing to do with compatability between vast combinations of hardware?

If it wasn't nVidia that asked for this and Google had instead announced that they would be instituting a form of Quality Standards it would have been hailed as visionary

Methinks too much fanboi thinking has crept into this thread and not enough common sense

 

[InvalidError]

[citation][nom]back_by_demand[/nom]So ... nothing to do with compatability between vast combinations of hardware?[/citation]
Most of what is required to make the "vast combinations of hardware" is covered by the PCIe, USB, SD and other specs which are all point-to-point so as long as the hardware follows its interface's spec with the relevant certification, it will be compatible with any other hardware out there. This works because hardware interfaces and specs are exactly the same for everyone, which makes it relatively easy to determine whether or not the device at the other end of the link implements the link protocol, configuration handshake and class-specific standard protocols properly.

When you get to the software side of things where each device manufacturer is maintaining their own forks of the reference Android platform with proprietary tweaks everywhere on a per-device basis, whatever certification you may slap on anything on one manufacturer's platform are worthless anywhere else even across the same manufacturer's other devices that run on different forks. If there were as many different Windows builds as there are OEM PC product lines out there, WHQL would be unmanageable and largely meaningless... all the WHQL certification proves is that the driver/device/software passed Microsoft's tests on a reference Windows build but does not guarantee it will work on any of the hundreds of OEM builds.

And as far as "quality standards" go, Google does have the CDD and CTS qualifications as requirements for Android branding which indicates that the device's firmware (at least the one(s) submitted for testing) has passed Google's compatibility testing. Whatever the means manufacturers used to achieve that are likely of little to no importance to Google.

Whoever asks for certification for a moving target (how many hundreds of forks does Android have?) is just asking for trouble since it is so grossly impractical as to be effectively impossible. Google's compatibility testing when a manufacturer applies for the right to use Android branding is about as far as Google can reasonably go.

 

[irh_1974]

[citation][nom]InvalidError[/nom]Whoever asks for certification for a moving target (how many hundreds of forks does Android have?) is just asking for trouble since it is so grossly impractical as to be effectively impossible. Google's compatibility testing when a manufacturer applies for the right to use Android branding is about as far as Google can reasonably go.[/citation]
As stated by someone else, it is impractical - difficult - so is your arguement that they should not bother and the limited controls in place are sufficient? I'm not sure what your position is on the subject, are you against a form of WHQL, or just because nVidia suggested it?

 

[InvalidError]

[citation][nom]irh_1974[/nom]As stated by someone else, it is impractical - difficult - so is your arguement that they should not bother and the limited controls in place are sufficient? I'm not sure what your position is on the subject, are you against a form of WHQL, or just because nVidia suggested it?[/citation]
My position is: certification on a platform that has hundreds of manufacturer-specific and device-specific forks in the wild is not merely "difficult", it is simply impossible.

There is very little value in a certification process on a standard/reference runtime when the reference runtime is the exception rather than the rule in the wild. So unless Google completely locks down the Android runtime by telling manufacturers that they cannot use Android branding unless they use the stock runtime, certification is futile since each fork needs to be re-tested individually.

 

[back_by_demand]

[citation][nom]InvalidError[/nom]My position is: certification on a platform that has hundreds of manufacturer-specific and device-specific forks in the wild is not merely "difficult", it is simply impossible.There is very little value in a certification process on a standard/reference runtime when the reference runtime is the exception rather than the rule in the wild. So unless Google completely locks down the Android runtime by telling manufacturers that they cannot use Android branding unless they use the stock runtime, certification is futile since each fork needs to be re-tested individually.[/citation]
So how does Microsoft do it? Surely the whole WHQL program has benefits and occasional issues, but they have at least got a program in place and everyone works together to try and minimise the impact of a fragmented hardware environment, so it isn't "impossible" it is "very hard"
...
And as you point out, Android would need to be locked down, but seeing as it is only 23% open source anyway that will make their job 77% easier
...
But reading your answer you still haven't actually answered the question, are you against a form of WHQL? Your answer was to reiterate that it was difficult, yes, we already know
...
Replace "moon" with "WHQL" and Kennedy could have been talking about this very subject

We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.

If it important enough and you have the funding, there is no limit to what can be achieved and Google certainly has the funds, it simnply appears that it does not garner a level of importance enough for them to take it seriously

 

[InvalidError]

[citation][nom]back_by_demand[/nom]So how does Microsoft do it? Surely the whole WHQL program has benefits and occasional issues, but they have at least got a program in place and everyone works together to try and minimise the impact of a fragmented hardware environment, so it isn't "impossible" it is "very hard"...[/citation]
How many supported runtime variations are available on Windows? Win7 and Win8 32/64bits. That's only four core variants. Server/Pro/Home/etc. are all the same code just with different arbitrary limits hard-coded in and different services enabled by default so I do not really count them as different versions. Microsoft has 100% control over Windows' code base.

How many variants of Android are out there? Hundreds, possibly thousands and Google has absolutely no control over any of them other than their own beyond granting or denying Android branding based on whether or not them manufacturer's implementation meets Google's requirements.

Do mind how you use that 23% figure. It stands for 23% open GOVERNANCE. Android's development process may be "23% Open" but the source code itself is 100% available for anyone to do whatever they want with. The only reason it got rated "23% open" is because Android is developed by Google for Google so Google reserves the rights to call all the shots for the mainline tree and the OSS community does not like being cut off the development process.

If you, Nvidia or whoever else are not happy with how Google wants to run their show and think you can build a better Android than Android, you can always make your own more-open Android fork and do whatever you want with it. Lets see if you are going to manage to do a better job at meeting Google's own Android feature and compatibility test suite when you apply for permission to use Android branding.

 

[back_by_demand]

[citation][nom]InvalidError[/nom]How many supported runtime variations are available on Windows? Win7 and Win8 32/64bits. That's only four core variants. Server/Pro/Home/etc. are all the same code just with different arbitrary limits hard-coded in and different services enabled by default so I do not really count them as different versions. Microsoft has 100% control over Windows' code base.How many variants of Android are out there? Hundreds, possibly thousands and Google has absolutely no control over any of them other than their own beyond granting or denying Android branding based on whether or not them manufacturer's implementation meets Google's requirements.Do mind how you use that 23% figure. It stands for 23% open GOVERNANCE. Android's development process may be "23% Open" but the source code itself is 100% available for anyone to do whatever they want with. The only reason it got rated "23% open" is because Android is developed by Google for Google so Google reserves the rights to call all the shots for the mainline tree and the OSS community does not like being cut off the development process.If you, Nvidia or whoever else are not happy with how Google wants to run their show and think you can build a better Android than Android, you can always make your own more-open Android fork and do whatever you want with it. Lets see if you are going to manage to do a better job at meeting Google's own Android feature and compatibility test suite when you apply for permission to use Android branding.[/citation]
Diversify the arguement, deflect onto another company, totally avoid the question - again
...
There are plenty of variants out there, but Google should have a total support mechanism for each official one they have pumped out, but let's be realistic and arbitrarily say that from Froyo onwards each one has it's equivalent WHQL - that is 5 official variants all the way up to Jelly Bean
...
MS has has WHQL for versions of Windows XP and all its SKU's, Windows Vista and all its SKUs, Windows 7 and all its SKUs and now Windows 8 - fair to say that is more than 5 variants
...
I totally agree that they should not have to support really old items, the same way WHQL wouldn't apply to DOS or Win 3.11, or variants that have been user modified - but if it is "made by Google" then it should be "supported by Google" with an appropriate and professional quality standards system
...
Simply holding up their hands and saying "hey guys, it's open source so you are on your own" is a total cop-out and defending it says you are either a Google employee or a blind fanboi, or both

 

[InvalidError]

[citation][nom]back_by_demand[/nom]There are plenty of variants out there, but Google should have a total support mechanism for each official one they have pumped out, but let's be realistic and arbitrarily say that from Froyo onwards each one has it's equivalent WHQL - that is 5 official variants all the way up to Jelly Bean.[/citation]
While there may be five variants straight out of Google, each of those gets customized by individual device manufacturers and Google has no control over those.

What you are asking for is something like telling RedHat to support your own fork of Fedora or RHEL. When you fork someone else's project, you are on your own.

 

[blazorthon]

[citation][nom]back_by_demand[/nom]There are plenty of variants out there, but Google should have a total support mechanism for each official one they have pumped out, but let's be realistic and arbitrarily say that from Froyo onwards each one has it's equivalent WHQL - that is 5 official variants all the way up to Jelly Bean.[/citation]
While there may be five variants straight out of Google, each of those gets customized by individual device manufacturers and Google has no control over those.

What you are asking for is something like telling RedHat to support your own fork of Fedora or RHEL. When you fork someone else's project, you are on your own.

The difference is that when you fork a Linux distribution, you aren't really affiliated with them. Like you said, you're on your on. With Android, it's not the same because you're expected to have your customized version be compatible with the other customized versions and with the original. Unlike forking a distro, you're not taking on a separate project of your own and your own naming when you work with Android on your phones and tablets and such, at least most of the time (Amazon and similar examples may be counted as excluded from that).

So, it really isn't the same thing as making a fork of a Linux distro, at least not when you're staying as part of the android ecosystem. If you can call it Android, then no matter how much you customize it, it should still be fully compatible with stock and customized versions from other Android partners, at least as far as app support and such goes.

 

[InvalidError]

[citation][nom]blazorthon[/nom]The difference is that when you fork a Linux distribution, you aren't really affiliated with them. [/citation]
Many distro forks attempt to maintain package compatibility with their source to avoid forcing everyone to make distro-specific rebuilds much like how Android forks, Google-approved or not, attempt to maintain compatibility with Google's Android so they can run most Android stuff and be targeted using the same Android development tools, IDEs and simulators.

Like it or not, the only legal (enforceable) control any company has over an open-source project is brand qualification. The most Google can do about device manufacturers starting to break Android is add test cases to their qualification test suites to catch those problems and deny Android branding on that basis.

Finding out how individual manufacturers messed up their own forks is not Google's responsibility.

BTW, notice how WHQL does not extend to any embedded platform? That is because Microsoft is leaving the burden of ensuring devices have drivers and whatever other necessary support software loaded and working properly in the manufacturers' hands.

 

[blazorthon]

[citation][nom]blazorthon[/nom]The difference is that when you fork a Linux distribution, you aren't really affiliated with them. [/citation]
Many distro forks attempt to maintain package compatibility with their source to avoid forcing everyone to make distro-specific rebuilds much like how Android forks, Google-approved or not, attempt to maintain compatibility with Google's Android so they can run most Android stuff and be targeted using the same Android development tools, IDEs and simulators.

Like it or not, the only legal (enforceable) control any company has over an open-source project is brand qualification. The most Google can do about device manufacturers starting to break Android is add test cases to their qualification test suites to catch those problems and deny Android branding on that basis.

Finding out how individual manufacturers messed up their own forks is not Google's responsibility.

BTW, notice how WHQL does not extend to any embedded platform? That is because Microsoft is leaving the burden of ensuring devices have drivers and whatever other necessary support software loaded and working properly in the manufacturers' hands.

The statement in bold is exactly what I was talking about! My whole point was that the other companies should be fully compatible with Android if they're going to make devices and call them Androids or such. Running most is not good enough.

I know from experience that not all manufacturers and such do a decent job when the responsibility is handed over to them. The custom Intel graphics drivers are oftentimes an excellent example of that.

 

[happyballz]

While there are issues with fragmentation I still pick a system that is more open and decide what hardware and software customization I get rather than a locked up one. That is my personal view.

Want a more redundant option as far as software compatibility then choose iOS, having said that I have yet to have software from Google's play store not work on my device.

 

[blazorthon]

While there are issues with fragmentation I still pick a system that is more open and decide what hardware and software customization I get rather than a locked up one. That is my personal view.

Want a more redundant option as far as software compatibility then choose iOS, having said that I have yet to have software from Google's play store not work on my device.

Google Play usually hides apps that aren't incompatible with your device IIRC. I've only seen it display non-compatible software once and it might have simply done that because I searched for all apps made by a certain developer.

Androids problems don't stop me from choosing Android devices either, but I'll still talk about them when the subject is relevant.