We have a theory: “Android Extensions” is a plan to bring the easily updatable app model to the AOSP APIs. Like Google Play Services, we think this app will be a bundle of API shims that Google can update whenever it wants. The difference is that everything in Play Services is a closed-source Google API, while “Android Extensions” would be collections of fresh AOSP code delivered directly to your device via the Play Store. The CDD’s stipulation that OEMs “MUST preload the AOSP implementation” is telling. It says that 1) this is AOSP code, and 2) OEMs aren’t allowed to “customize” it.
If Ars’ assumptions are correct, this looks like a decent step forward – assuming it pans out, of course. Clever, too.
That doesn’t address the core problem.
Yes, it is yet another proof that Google just doesn’t have the guts to update the Android Compatibility Definition Document to require full platform updates.
Because most phones are heavily customized and the customization will break if the OEM doesn’t adapt the code to the new platform version. And OEMs have a finite amount of devs working on the code.
I do not want platform updates for customized phones like my sister’s Galaxy S6 (btw she likes how Samsung’s UI works and wouldn’t change it for the UI of my Nexus 5X), I want security updates. Don’t know if the thing the article describes is a fix for security updates…
Edited 2016-11-09 17:31 UTC
Then the OEMs can find another way to handle their custom apps/skins, and Google can forbid their modification of core Android to meet their compatibility specs. However, unfortunately, this would require Google to give a f*** about backward compatibility which, for their part, they never will.
What it’s going to come down to in the end is forbidding extensive OEM modifications to Android. I know I wouldn’t complain especially since Samsung’s fork is a nightmare when stuff goes wrong for inexplicable reasons.
Oh, and… the carriers. They need to be absolutely forbidden from modification of anything whatever at this point. They’re even worse than the OEMs.
The market has decided it wants modifications, otherwise we ‘d all be using Nexus 4, Nexus 5 and Nexus 5X phones. In fact, to the average customer, my Nexus 5X looks “barebones” both in terms of UI and also features (“you mean it doesn’t go to a special screen when you plug in headphones?”) What you refer to as the “TouchWiz skin” is actually a deep fork of the OS. Customers like those deep modifications, at the very least because it gives them the illusion of choice.
Disallowing deep modifications to the OS would alienate customer and OEMs for security benefits that aren’t apparent to neither of the two groups. So… Google being able to apply API patches on top of old platform versions is the best you can hope for. After all, in order to engage any kernel exploit like “Dirty COW” you have to use some API calls, so those APIs can be patched to filter the exploit code. You can always choose “pure” OSes like Jolla or Ubuntu Touch, but don’t expect the market to do it en masse.
Edited 2016-11-09 19:20 UTC
kurkosdr,
Actually, I think Nexus would be far more popular at a lower price. I’m not saying it makes economic sense for google to do that, but for me personally spending that amount for a phone is outrageous. If not for that little caveat, I’d probably be using a Nexus right now.
I got a Nexus 6P for $400 (and I think it was only $500 when it was new), which is less than half the cost of the latest comparable iPhone or Galaxy device (~$850). I can’t say Nexus is expensive – The Pixel is expensive, but the Nexus 6P had a decent price.
Where are you located? In the states, a Nexus 6P was $649 at launch–same price as the comparable iPhone or Galaxy base model. Still far too expensive but this is what happens when we allow cost to be hidden by carrier subsidies.
It just depends on what you can justify as cost for a smartphone. My wife gets 250€ from work every 2 years for a new model. I don’t see any reason why I should spend more, they are working fine for normal usage.
Located in Belgium, prices are in Euro, but the difference in price range should be clear.
The Nexus 5 was as cheap as a phone that Google can confidently slap their name on can be. Yet it barely made a dent to the market of customized phones.
It wasn’t given away for $20 with a new or renewed contract either though.
Because the kind of devices given away for $20 with a new or renewed contract are the kind of device Google cannot put their name comfortably on.
The Nexus 4 especially was as cheap as a good phone could ever be. Still didn’t make a dent on customized phones.
And anyway, people buy Galaxies and LG Gs and Xperias that are much more expensive than the current Nexus 5X. In fact, the more dough a customer has, the more likely to buy a customized phone full of bells and whistles. Not buying a Nexus might have been a price issue for you, but for many many people it isn’t. It is a bells and whistles issue.
Edited 2016-11-09 21:28 UTC
kurkosdr,
Well, I don’t claim it made sense for google to go cheaper, only that it was never an option for some of us due to it’s higher price point.
“The market has decided it wants modifications, otherwise we ‘d all be using Nexus 4, Nexus 5 and Nexus 5X phones.”
This conclusion makes a broad assumption that modifications are the only reason consumers choose alternatives. Correlation <> Causation.
And you’ve just made my point for me. I was mostly going for irony that now that Google have made their bed, band-aids are about the only way they can hold it together. What I said about carriers still stands though. Keep them out!
darknexus,
I am of a slightly different opinion. To paraphrase a popular saying: I may not like your modification, but I’ll defend your right to modify it.
Being able to modify code is one of the principal tenants of open source. There is indeed a problem, but it’s not OEMs modifying android, it’s that users can’t modify it as well independently from the OEM. For example, a user unsatisfied with the OEM updates should be able to modify an OEM phone back to vanilla by themselves.
We didn’t really have this problem in most eras of the x86 PC. When you bought one, sure it was bundled with an OEM version of dos/windows, but you were never obligated to stick with those for the life of the hardware. Sure enough, many people would end up removing OEM modifications and installing a newer version of the operating system. No consent was needed and the process was technically viable without much skill. One could even install a 3rd party OS or write one’s own, which I did and loved.
For better or worse, ARM devices evolved into black boxes with strongly bundled software. The millions of consumers who were comfortable upgrading x86 machines themselves, now find themselves at the mercy of their OEMs for all updates. Even those who manage to obtain root access, like myself, are helpless to replace the OS because the drivers and boot environment for the ARM SOC are proprietary.
This next observation isn’t going to be popular, but the linux kernel itself deserves some of the blame due to it’s being monolithic and lacking stable ABIs. This leads to drivers that are compiled specifically for the bundled OS rather than for a abstraction of the OS, which prevents us from being able to reuse the OEM’s drivers with newer kernels.
One last point, prohibiting OEM modification doesn’t necessarily do that much to change the status quo. For example, my Blu phone is fairly close to stock android, but I’m still waiting along with everyone else for an update that might never come. So instead of requiring every android phone to be the same, I really wish google would use it’s weight to transform ARM into an open platform such that this would not be a problem to begin with (not that I’m holding my breath…
)
We are in complete agreement there. Ironic that the very lack of something a lot of Linux zealots say would make commercial drivers too easy to develop is the thing keeping us locked into those commercial drivers with no way out. There’s a lesson in there somewhere, I think.
Edited 2016-11-09 20:37 UTC
Alfman not based on history of what has been done and what as failed and what is going down now.
Number 1 Linux kernel does have stable ABI for drivers in user-space.
Number 2 Linux kernel did at one point of history provide stable kernel space drivers for drivers.
https://en.wikipedia.org/wiki/Uniform_Driver_Interface
Everyone likes to forget the Uniform Driver Interface. So what happened here since driver developers could see the source code that was not inside the Uniform Driver Interface stable api proceed to connect to API not defined as stable so making the project absolutely useless.
Alfman the reason why the Linux kernel gives up having a stable kernel space ABI is the fact driver developers would not in face obey it because driver developers want the fastest performance even if this results in snapping. This is why under Windows when you turned on NX fir the first time a stack of drivers failed.
Alfman it takes two to tango.
Linux kernel providing stable ABI for kernel space only make sense is driver developers are going to play by the rules. The history of Windows/BSD/Linux with binary drivers tell us pass question driver developers will not play by the rules unless they have to have their drivers certified independently or where the drivers are running there is no access to ABI that is not stabilised.
Next killer to the idea of Linux kernel requiring a binary driver ABI comes from EFI.
http://cateee.net/lkddb/web-lkddb/FB_EFI.html
Most people overlook that EFI loading systems can provide EFI drivers to the OS loaded EFI bootloader.
So does Linux really need a binary kernel driver ABI any more. I would say mostly no as EFI Drivers is the second form of binary drivers for Linux. Write it into EFI spec and have all OS out there use the same set of drivers that are closed source.
Now vendors providing EFI drivers
1) Vendors Would not have to obey GPL.
2) Vendors could not go and use interfaces provided by the Linux kernel that are not standardised.
3) Vendors would have to work on extending EFI to include the features they want.
Due to the history of ndiswrapper loading windows network drivers on Linux there is no reason why there could not be a EFIwrapper loading EFI drivers under Linux.
Now this is that driver makers provide enough EFI drivers that it worth the Linux time and they in fact standardise making drivers.
Drivers standardised in EFI would be end user OS neutral.
The reality if we want binary drivers for Linux the reality is how it has to be implemented is as a platform neutral solution so vendors are 100 percent sure that there drivers are not a derivative work as defined in GPL.
Yes this is two to tango parties wanting kernel mode closed source drivers for Linux solutions are being provided issue is lack of usage and development and that they are platform neutral so people don’t normally associate them with Linux.
So the statement in the Linux about the Linux kernel not needing a binary driver interface is absolutely correct. We need a OS neutral binary driver format being used in volume. Issue is people keep on asking for the wrong thing without understanding limitations GPL applies.
oiaohm,
I knew it wouldn’t be popular
I really appreciate your suggesting several solutions, they do exist and I agree with many of your assertions. What we are fundamentally missing however is cooperation. As you observe, manufactures have very little interest in releasing source, yet the the Linux community are ideologically uninterested in supporting stable binary drivers. We’re at the same crossroads we were at with UDI in 1998. It’s hard to see that either side will give in. And while google could throw it’s weight to get results, it probably doesn’t really care.
I really don’t know how we get unstuck. I don’t predict any progress whatsoever over the next ten years because no one is going to back down from their ideological stance. To be perfectly honest I worry that there is a serious risk of being even more locked down.
Edited 2016-11-10 16:26 UTC
http://projectudi.sourceforge.net/
UDI was not Linux only. The lack of UDI drivers really has nothing to-do with what you are pointing to.
UEFI standard does not say that a UEFI graphic driver has to be framebuffer only. VESA BIOS is an example of Linux working with a Binary driver. VESA BIOS was the driver and the Linux kernel was coded to talk to it. So using a VESA framebuffer under Linux and you change kernels you are in fact using the same binary driver that happened to be stored in BIOS.
Most android devices don’t support VESA framebuffer as the graphics cards they have are not to VESA standard.
Is there anything forbidding a more complex protocol covering like KMS and GPU control coming from a UEFI graphics driver the answer is in fact no there is not.
UEFI does not even restrict the types of drivers that can be provided as UEFI drivers.
Most of the issue is that Linux is monolithic that people fail to notice how often Linux historically has used binary drivers provide by firmware. UEFI is the new firmware. UEFI can have update installed from Linux these days.
Issue is a UEFI binary driver is most likely going to be like NDIS or UDI slightly low performing than native Linux drivers that are monolithic. Linux kernel being monolithic allows it to be speedy.
Alfman Linux kernel developers support using firmware features. Ideological arguement is right and wrong basically. Linux kernel developers want to be able to alter the open source stuff under GPL as much as they like in kernel space for performance.
So there is no need for Ideological argument over binary drivers with the Linux kernel if the binary drivers are provided by firmware/UEFI/BIOS.
Now if you are wanting the Linux kernel itself to support unique binary drivers to Linux then you are in Ideological war.
Other problem you have is thinking Linux kernel is like Stallman.
https://en.wikipedia.org/wiki/Linux-libre
Stallman is anti anything closed this include firmware blobs the Linux kernel project normally ships.
So yes Linux developers have made it very clear what form of binary drivers they will put up with. That is binary drivers provided by firmware/UEFI/BIOS.
The EFI Framebuffer example that is being merged mainline Linux shows to support this path the Mainline Linux developers will cooperate. Now how do we get hardware developers to cooperate on providing EFI drivers is now the big question.
How to move forwards with binary drivers for Linux is don’t have them for Linux but have them as generic binary drivers for everyone. This would be good for competition between Linux and BSD and other OS options as well.
oiaohm,
I’m not going to argue with you about this, I already know that Linux can do all these great things in these great ways. I love that about linux, you are already preaching to the choir. I could concede to nearly everything you are claiming, but you are still fundamentally missing the point. None of that helps me solve the upgrade problem whatsoever when my device ships with unstable binary drivers tethered to a specific kernel.
As a member of and developer for the linux community, we can defend linux all day long and blame others. But no matter how strongly we feel we are right, if we don’t come through for users, then we’ve failed. Users need pragmatic solutions, not rhetoric.
Edited 2016-11-10 20:00 UTC
The thing is the solution exist. The solutions need more resources and end users and OEM demand the support.
Sorry you can attack linux over these faults day in day out. It does not change the fact that solutions to this problem appear time and time again and people are not out their yelling for EFI drivers or UDI drivers…. So we end up back in the case of lets use possible illegal drivers over and over again.
So the problem is not blame Linux kernel developers any more. The question is how to apply force so vendors will go the 100 percent sure legal path and move away from the path that is causing end users hell.
Users and OEM asking for Linux driver support instead of EFI driver support results in them being given kernel-tethered binary drivers.
So closed source driver should be like EFI or UDI and open source driver can be kernel-tethered. Then we would not have most of the problems. This is not going to happen if this is not what we a requesting.
oiaohm,
While there may be some truth in that, it’s got a “do as we say, not as we do” vibe to it. For change to really work linux would have to embrace stable ABI’s from within and not just continue the status quo. This is why we deserve some of the blame ourselves.
Edited 2016-11-11 16:55 UTC
Binary drivers would not be as big of issue if what was going on is “do as we do”.
Linux kernel unstable kernel space ABI has allowed the Linux kernel to change a lot to increase performance that would not have been possible if the kernel space ABI was stable.
So “do as we do” means since the Linux main developers release open source everyone need to release open source something. Nvidia releases an open source wrapper to connect their binary blob to the Linux kernel. That wrapper can be modified if the kernel changes.
Nvidia arguement against using UDI was using only the interfaces UDI provided they could not get performance.
Nvidia gets the functions they use in kernel space stabilised to Linux user-space before they use them in the wrapper. So if you cannot code your binary driver in user-space linux you really should not ship it as it not using functions that are define stable.
Nvidia is the longest maker of binary drivers for Linux. Not following Nvidia path at a min is truly playing russia roulette with the courts.
So when Nvidia who makes binary drivers can do it legally right why should any of the arm guys who are doing it legally wrong get a free ride.
The reality is binary driver interface for Linux cannot come from with in due to the license Linux kernel is under. So binary driver interface has to be adopted by Linux. This is why UDI and EFI drivers are correct path.
Once you allow for the legal limitations there are not many options at all. Really limits what you should be attempting to request.
The problem is coming because many parties are not playing by the legal rules.
oiaohm,
Oh I’m well aware of this, and the photo of Linus giving Nvidia the middle finger
However your response never the less highlights the very thing I was alluding to when I pointed out that so long as neither side is willing to change their ideological stance, then no progress will be made. Linux and OEMs are both responsible for the driver situation we find ourselves in.
Problem is its not what programmers believe but what courts believe and how they take the license. GPL has been confirmed viral in courts a few times over.
Yes Android N using openjdk parts is because there is no way to win against how GPL viral works unless you return to tradition black box development with all the extra bugs that causes.
This is the problem you want the interface defined under some other license other than GPL if you are wanting to-do closed source binary.
Alfman that nothing you really said legally flies enough to be a international solution means your ideas are stuffed for something like Linux that has to operate internationally.
UDI/EFI binary drivers do legally fly internationally.
oiaohm,
Oh and one more thing, quit being a condescending dick, alright
No seriously though, this is one of the things that’s most off-putting about linux community sometimes. Users just want solutions and they come seeking help, they’re taking their steps to engage with and participate in the FOSS community, but instead of solutions and encouragement all too often they’re brushed off with all kinds of preachy bullshit. Evangelicals often have the best of intentions, but they can be too authoritarian and close minded for the good of the community. This attitude of “this is the only right way, your ideas are stuffed” can damage the very community that we’re both trying to promote.
I’m a linux professional, a FOSS supporter, and even I’m frustrated by what I can’t do with my linux phone because of our collective refusal to budge.
We can agree to disagree, but in the back of your mind I’d like to to consider that stubbornness is not always the best way to serve the community. I probably need to keep that in mind as well
Edited 2016-11-12 20:49 UTC
No go and learn the legal rules at play. Once you do you understand why something never can fly. Linux kernel providing a binary interface for kernel drivers directly is one of those things that just cannot legally fly without re-licensing the complete project.
Now if some third party be it Microsoft or anyone provides a binary driver interface under a not GPL/not CDDL/not viral license than Linux can implement then you have solution.
Please note CDDL license of Solaris means that Solaris binary drivers cannot be used under Linux. SUN did this intentionally. This viral license nightmare for drivers apply to Solaris and Linux in different ways. So the ZFS kernel space driver for Linux has to ship as source and be built on target to be legal.
So License conflict issues are forced to be handled particular ways or risk being illegal.
Stop calling this stubbornness. Legal rules have to be obeyed. There is a path around these problems but its not what you are talking about.
oiaohm,
So condescending, so arrogant, I should have figured it out sooner, you’re intentionally trolling me. And here I was thinking you were serious. Well played. If you want to continue, take it up with Torvalds
I am not saying this cannot be done. But you have to prove the documentation you have written has not be tainted by access to the GPL parts. Other wise you had no legal right to put the documentation under public domain. UDI or something like it is simple because the exposed interfaces don’t match the GPL protected one so is really simple to argue and win no taint.
So to get around the Linux kernel license issue with no possibility of losing in court you need a independent project to the Linux kernel for binary drivers for Linux and another platform under a license like MIT or Public domain… something non viral that the Linux kernel can have a compatibility interface to. Then you can have legal binary drivers without question.
Once you get your head around the License issue of the Linux kernel your options are very limited.
I could not find the link that covers it all but you just did.
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
Yes this page covers from 1995 to 2005 of debate and legal review over the state of the Linux License. If you read to the bottom its insanely hard case to have a closed source binary kernel driver using any parts of the Linux kernel source documentation or header files. Deeper legal review most of the documentation about building Linux kernel drivers would also be classed as tainted.
So asking the Linux kernel project to provide a stable kernel closed source binary abi is asking the impossible because the license is wrong and they are needing a third party to provide a correct work around to the license issue. Effectively making the Linux kernel 2 projects 1 project for open source drivers/core and 1 project for closed source drivers these two project would have to remain independent for ever more.
Asking the Linux kernel developers to support a independent project for binary drivers becomes a chicken and egg problem due them in past being burnt by UDI where they will want to see volume of drivers using the interface for it to be worth their time.
Alfman I am not troll you I have read all the key documentation about this problem. After you read it all you wake up the options to provide a closed source kernel binary driver interface for Linux is insanely limited and it all because the license is wrong.
There is no simple way to fix it bar starting another project and having a compatibility interface from the Linux kernel to that project interface for drivers.
oiaohm,
The trolling gig is up. Like I said, take it up with Torvalds if you think he’s wrong about modules. If you get him to change his mind, submit an article about it to osnews. Until then, oiaohm
Edited 2016-11-13 12:25 UTC
Alfman Linus corrects himself in 2002 on the very thing you quoted about on the very page you argument depends on.
So I absolutely to agree with Linus statements about the license of the Linux kernel once he had got correct legal advice over what he had one.
Sorry if anyone was trolling with incorrect fact it was you.
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
So go and read the page you quoted top to bottom not just the top bit that is the oldest out of date information.
If you don’t agree with what I am saying you need to take it up with current day Linus and be the next idiot to lose because they did not understand what the license on Linux in fact means.
Reality Alfman you out of context quoted something to win. You would have known that if you had read the page and notice what Linus said in 1995 totally does not agree with what Linus says in 2001 and 2002.
Even 1998 Linus is very clear that ‘derivative work’ status has to be proven not to be for a closed source driver or the driver has to be under GPLv2 or compatible license.
This means every closed source driver for Linux has to fight on a case by case base. Most drivers that are only for Linux it would be next to impossible to prove they are not ‘derivative work’.
Key question for if something is not a derivative work is do they function if the GPL part is removed.
Alfman basically read the
Date: Thu, 17 Oct 2002 10:08:19 -0700 (PDT)
Email by Linus on that page. Notice all mention of LGPL is gone. Why because the LGPL license was never bundled with the Linux kernel only the GPL one.
The historic mistake is small but insanely painful. LGPL was not even including when modules and kernel shipped as two tar.gz files instead the single GPLv2 with exemption was used on everything.
Sorry Alfman your trolling gig is up quoting a page without fully reading it all that is normal troll behaviour. You need to read it all to understand why your request was not going to happen and where the wall was.
Having people write binary drivers for linux using a kernel stable binary abi and losing in court because they have not taken account of GPLv2 limitations would be a huge black eye. Having the kernel binary ABI unstable is is a barrior.
Next you are aware the Linux module loader until 2001 did not check for many signature things. So you could load modules build for different kernel modules back then.
So the stable binary module loading has been intentionally disabled by none other than Linus due to the legal problem. In fact you can go into kernel config you find the feature MODVERSIONS with status off. What is the feature that allows loading kernel modules built for different kernels.
I asked a long time ago why MODVERSIONS was off.
Of course Alfman you never checked if the feature you were asking for existed in the Linux kernel and was just disabled and disable for legal reasons. So what is missing is a clean ABI legal to use before that loader code can be used safely and enabled.
So there is nothing more for the Linux kernel to implement until third party provide missing part as the feature you want is implemented as far as the Linux kernel project itself can legally go.
The second last piece has to come from a outside Linux kernel project. Then the last piece is alter the loader to identify and load code built to the outside Linux kernel project standard.
You can compile any new API from the Android SDK all the way back to API 15 in most cases (Android 4.0.3) or even beyond. To say they don’t care about backward compatibility is ridiculous.
Edited 2016-11-09 20:27 UTC
The basic fact is that the vast majority of Android users don’t give a whit about security, either of their identity or their data. That’s it, plain and simple. If they did, they would demand that their carriers and device manufacturers at least guarantee that their device will receive the monthly official security updates. But they aren’t doing that, so there really isn’t anything Google can do about it, other than release new requirements like this, and you can see what sort of response it has brought on. Those Android users are perfectly fine with being able to download software from any provider they choose, no matter how shady or even if they know that provider is going to steal their data and use their phone in a botnet. They want the ability to open a box, turn on their new phone and immediately change EVERYTHING about it, the OS, launcher, icons, anything, regardless of whether any of that is compatible with stock Android or whether any of it compromises the security of their identity or their data. They just don’t care, and want the freedom for that to happen. They don’t care that it might put others at risk either. It’s a nightmare scenario that will eventually result in some massive meltdown of a huge number of phones, but hey, that isn’t my concern either. Or Google’s.
Edited 2016-11-10 11:50 UTC