Linked by Thom Holwerda on Wed 9th Nov 2016 15:55 UTC
Android

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.

Order by: Score:
Yet another band-aid
by jbauer on Wed 9th Nov 2016 16:44 UTC
jbauer
Member since:
2005-07-06

That doesn't address the core problem.

Reply Score: 5

RE: Yet another band-aid
by moondevil on Wed 9th Nov 2016 17:18 UTC in reply to "Yet another band-aid"
moondevil Member since:
2005-07-08

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.

Reply Score: 2

RE[2]: Yet another band-aid
by kurkosdr on Wed 9th Nov 2016 17:30 UTC in reply to "RE: Yet another band-aid"
kurkosdr Member since:
2011-04-11

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

Reply Score: 4

RE[3]: Yet another band-aid
by darknexus on Wed 9th Nov 2016 18:09 UTC in reply to "RE[2]: Yet another band-aid"
darknexus Member since:
2008-07-15

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.

Reply Score: 2

RE[4]: Yet another band-aid
by kurkosdr on Wed 9th Nov 2016 19:18 UTC in reply to "RE[3]: Yet another band-aid"
kurkosdr Member since:
2011-04-11

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.


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

Reply Score: 4

RE[5]: Yet another band-aid
by Alfman on Wed 9th Nov 2016 19:46 UTC in reply to "RE[4]: Yet another band-aid"
Alfman Member since:
2011-01-28

kurkosdr,

The market has decided it wants modifications, otherwise we 'd all be using Nexus 4, Nexus 5 and Nexus 5X phones.


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.

Reply Score: 3

RE[6]: Yet another band-aid
by CaptainN- on Wed 9th Nov 2016 20:31 UTC in reply to "RE[5]: Yet another band-aid"
CaptainN- Member since:
2005-07-07

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.

Reply Score: 2

RE[7]: Yet another band-aid
by darknexus on Wed 9th Nov 2016 20:35 UTC in reply to "RE[6]: Yet another band-aid"
darknexus Member since:
2008-07-15

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.

Reply Score: 2

RE[7]: Yet another band-aid
by spinnekopje on Thu 10th Nov 2016 07:04 UTC in reply to "RE[6]: Yet another band-aid"
spinnekopje Member since:
2008-11-29

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.


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.

Reply Score: 1

RE[6]: Yet another band-aid
by kurkosdr on Wed 9th Nov 2016 20:46 UTC in reply to "RE[5]: Yet another band-aid"
kurkosdr Member since:
2011-04-11

kurkosdr,

"The market has decided it wants modifications, otherwise we 'd all be using Nexus 4, Nexus 5 and Nexus 5X phones.


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.
"

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.

Reply Score: 2

RE[7]: Yet another band-aid
by darknexus on Wed 9th Nov 2016 21:09 UTC in reply to "RE[6]: Yet another band-aid"
darknexus Member since:
2008-07-15

It wasn't given away for $20 with a new or renewed contract either though.

Reply Score: 2

RE[7]: Yet another band-aid
by Alfman on Wed 9th Nov 2016 21:24 UTC in reply to "RE[6]: Yet another band-aid"
Alfman Member since:
2011-01-28

kurkosdr,

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.


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.

Reply Score: 2

RE[5]: Yet another band-aid
by darknexus on Wed 9th Nov 2016 20:32 UTC in reply to "RE[4]: Yet another band-aid"
darknexus Member since:
2008-07-15

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!

Reply Score: 2

RE[4]: Yet another band-aid
by Alfman on Wed 9th Nov 2016 19:39 UTC in reply to "RE[3]: Yet another band-aid"
Alfman Member since:
2011-01-28

darknexus,

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.


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... ;) )

Reply Score: 3

RE[5]: Yet another band-aid
by darknexus on Wed 9th Nov 2016 20:37 UTC in reply to "RE[4]: Yet another band-aid"
darknexus Member since:
2008-07-15

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.

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

Reply Score: 2

RE[5]: Yet another band-aid
by oiaohm on Thu 10th Nov 2016 06:39 UTC in reply to "RE[4]: Yet another band-aid"
oiaohm Member since:
2009-05-30

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.


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.

Reply Score: 3

RE[6]: Yet another band-aid
by Alfman on Thu 10th Nov 2016 16:11 UTC in reply to "RE[5]: Yet another band-aid"
Alfman Member since:
2011-01-28

oiaohm,

I knew it wouldn't be popular ;)

Number 1 Linux kernel does have stable ABI for drivers in user-space.


It's not applicable here, and not ideal anyways.

Number 2 Linux kernel did at one point of history provide stable kernel space drivers for drivers.

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.


Good observation! It would have been interesting to see UDI succeed, but it had neither the support of microsoft, nor the support of free software advocates like Stallman, who were each resistant to cooperating with the other side. I'll leave this link here for historical reference:

http://www.linuxtoday.com/developer/1998100500205OP


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.


I fail to see how NX would fundamentally be a problem?
Anyways Linux already has an ABI, it's just not stable.


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.


You are absolutely right. While we can debate WHY it's monolithic, my point was simply that BECAUSE it's monolithic, we end up with drivers than can't be reused in upgraded kernels.


Next killer to the idea of Linux kernel requiring a binary driver ABI comes from EFI.
Most people overlook that EFI loading systems can provide EFI drivers to the OS loaded EFI bootloader.



In principal I don't really care where the drivers come from. Keeping drivers in EFI doesn't bother me, as long as they have a standard public ABI.

In practice, a framebuffer driver, like VESA BIOS before, is good for fallback, but falls short for accelerated usage. I'm not even sure how many android phones support this today?


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.
...
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.



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

Reply Score: 3

RE[7]: Yet another band-aid
by oiaohm on Thu 10th Nov 2016 17:57 UTC in reply to "RE[6]: Yet another band-aid"
oiaohm Member since:
2009-05-30

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.

Linux community are ideologically uninterested in supporting stable binary drivers

This is a mistake UDI was at one point merged mainline in Linux kernel than deprecated due to lack of drivers. So Stallman was not really a factor to the failure UDI.

UDI lasted until 2003 then no more drivers came. This is purely hardware vendors not making UDI drivers.


Sorry the ideologically uninterested is false if this was the case items like ndiswrapper would never get up. UDI is like Ndiswrapper Linux world had both while they provide a driver advantage.


I fail to see how NX would fundamentally be a problem?


NT driver writing guide by Microsoft said you should never have for executable in data memory in a kernel driver and executable data in kernel space should be read only. So every NT driver designed to Microsoft instructions should never of failed when NX bit was turned on yes every driver that failed with Windows XP when NX was turned due to driver developers using code rewriting for performance was breaking the rules.

Yes this was around the same time UDI died. So driver developers writing rule breaking drivers is nothing new or unique at the time. The death of UDI was striking UDI drivers that 1 were never made 2 were never update or 3 the worse single OS only because they went and used some function that only owned to 1 OS.

You are absolutely right. While we can debate WHY it's monolithic, my point was simply that BECAUSE it's monolithic, we end up with drivers than can't be reused in upgraded kernels.


This is wrong. When someone was using UDI or NDISwrapper driver they upgraded Linux kernel and kept on using the same driver.

So Linux kernel being monolithic has nothing really to say there cannot be binary drivers.

EFI driver
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Drivers
Note the UEFI Framebuffer driver being used by Linux goes outside what UEFI use to define as a driver that OS could use.

http://cateee.net/lkddb/web-lkddb/FB_EFI.html
So this is EFI standard evolving.

In practice, a framebuffer driver, like VESA BIOS before, is good for fallback, but falls short for accelerated usage. I'm not even sure how many android phones support this today?


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.

Reply Score: 2

RE[4]: Yet another band-aid
by CaptainN- on Wed 9th Nov 2016 20:27 UTC in reply to "RE[3]: Yet another band-aid"
CaptainN- Member since:
2005-07-07

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

Reply Score: 3

wocowboy
Member since:
2006-06-01

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

Reply Score: 2