For clarification Google took out support for the popular 800/801 chip from AOSP which meant vendors wouldn't pass CTS if they update to Nougat anyway. Seems that the requirement for N is having a Vulcan/OpenGL ES 3.1 capable device[1]. Which is a bit bullshit from the side that in regular usage this isn't warranted and that even target apps for that (entertainment) don't have those kind of support.
So, since Sony Z3 series running this SOC was very popular (and completely capable of running Android 7, Z3 even had a N preview), seems Sony will try to hint the community into building a custom ROM.
But probably it will have incomplete/unstable camera binaries, because they aren't open source.
I believe the answer will turn to be encryption support. Snapdragon 800/801 doesn't have instructions for AES operations acceleration (the equivalent of AES-NI on Intel processors) and Google seems to want to make encryption a standard feature of Android.
> For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience. If a device implementation is already launched on an earlier Android version with full-disk encryption disabled by default, such a device cannot meet the requirement through a system software update and thus MAY be exempted.
This doesn't refute your point, just illustrating the previous requirement for FDE. Curious to see the 7.0 CTS standards when they're published.
Might be, there have been some speculations already[1] and it makes sense.
But still come on, I bet most of the users don't encrypt their existing devices. And if Google is trying to do this in the name of security, they've just excluded a huge pile of devices newest Android security fixes.
Planned obsolescence at its best, specially since 810 was overheating, battery draining shit show and 820 is only slightly improved. 800/801 were excellent.
I own both a 801 device (LG G3) and a 810 (Sony Z4). The 801 runs way hotter than 810 with frequent throttling. There are times I have to stop playing a game because my fingers are burning! At XDA you will even find hardware mods for cooling the CPU. :)
Unfortunately this is the only way for Android team to enforce good practices to most manufacturers. If not, you would still see new devices coming out without usable encryption support. The older handsets will still be protected by Play Services as long as they stay mostly in Play Store and don't install random apks from the net.
Yes, planned obsolescence is an issue, especially for countries or groups with lower income. On the other hand phones get such an abuse through daily use that few of them last for 3 or more years.
It is depressing to see such cavalier attitude towards backwards compatibility and older devices (flagships even, assuming you are talking about Snapdragon 800 devices).
This is planned obsolescence at its worst .. :/
(At this point, Android management seem to be thinking "What are the other alternatives, Windows 10 Mobile .. haar, haar ..")
On the other side of this controversy are developers who want to use Vulkan and other features which require hardware support, and they are tired of dealing with runtime API capability checks (A.K.A. "fragmentation"). You cannot have backward-compatibility for these features if you require support for them in hardware.
This is more a cavalier attitude on the part of Qualcomm who do not support their own hardware for a reasonable length of time, and who do not foster open-source driver development which would at least allow the community to bring new features to older hardware in some cases (Vulkan being the prime example).
> On the other side of this controversy are developers who want to use Vulkan and other features which require hardware support, and they are tired of dealing with runtime API capability checks (A.K.A. "fragmentation").
Imagine Microsoft blocked Windows 10 (or any of the next builds) from all the GPUs who don't support DirectX 12, so that the developers can write DX12 software more conveniently.
This obsolescence of multiple hundred $€Ł mobile devices inside 18 months is getting silly.
Imagine if Apple no longer released OS updates for devices incapable of running Metal, and they pushed updated drivers for devices already on the market, thus enabling both developer convenience and consumer trust. Oh wait, you don't have to.
Your frustration is misdirected. The CTS and Google Play Services are the only tools at Google's disposal for inducing market changes. Perhaps manufacturers will demand longer support periods for upstream hardware, for instance.
In my opinion Google is between a rock and hard place. They made it very easy to be certified for Android. My assumption for the reason is to spread it everywhere to get market dominance.
Now they are tightening it up a bit which as a developer I support but honestly end users are being screwed, and the root cause is Google not Qualcomm in my opinion. Google could have from the start been stricter about certification if they really cared about delivering a good experience to end users and developers, rather than just sending out a shitty product quickly.
If an app requires a minimum SDK version of 24, this change means they cannot rely on an available OpenGL ES 3.1 or Vulkan implementation, which is contrary to the official documentation.
So "most apps" will "perform fine" unless they rely on CTS guarantees. If they want to fix the inevitable crashes on third-party ROMs, they will need to perform the same API-level checks that apps needed to perform pre-Nougat. Which is the definition of "fragmentation".
Sony has been doing it for a while for the Z-range. In fact, they even provided N Preview images for the Z3, as the first and only non-Nexus.
The Xperia Z has a fully functional (all hardware, no major issues) Android 4.4 build a week after the 4.4 sources were released. It was the first non-Nexus with a working KitKat. Sony provided the right stuff on GitHub and their devices are very easy to develop for.
The only caveat, of course, is that if you unlock the bootloader on at least the Z3 and up, you lose a bunch of "protected" functionality, including what makes the camera on these devices great. It's for this reason that my Z5c is, and will likely remain, forever locked.
I used a root exploit to obtain permanent root on my old Z3c, but it felt kinda pointless since I couldn't install CM without unlocking the bootloader. (Yes, locked root made it possible to back up the DRM partition, but running CM without the DRM partition intact and the bootloader unlocked meant living with sub-optimal camera performance, so that was a non-starter for me too.)
So yes, Sony's devices are "easy to develop for", if you don't mind living with crippled hardware features (permanently, in the case of the Z5) once you unlock the device.
It's also hilarious that they're protecting their knowhow like this, where Sony imaging postprocessing of taken pictures is really bad.
They ship capable camera sensors on their devices and are outperformed by other vendors who use their same sensors, but don't suck at image processing.
25 comments
[ 2.8 ms ] story [ 68.1 ms ] threadSo, since Sony Z3 series running this SOC was very popular (and completely capable of running Android 7, Z3 even had a N preview), seems Sony will try to hint the community into building a custom ROM.
But probably it will have incomplete/unstable camera binaries, because they aren't open source.
Android is a mess.
[1] http://www.androidcentral.com/Android-7-snapdragon-800
> For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience. If a device implementation is already launched on an earlier Android version with full-disk encryption disabled by default, such a device cannot meet the requirement through a system software update and thus MAY be exempted.
This doesn't refute your point, just illustrating the previous requirement for FDE. Curious to see the 7.0 CTS standards when they're published.
But still come on, I bet most of the users don't encrypt their existing devices. And if Google is trying to do this in the name of security, they've just excluded a huge pile of devices newest Android security fixes.
Planned obsolescence at its best, specially since 810 was overheating, battery draining shit show and 820 is only slightly improved. 800/801 were excellent.
[1] http://www.androidauthority.com/android-7-0-snapdragon-800-8...
Unfortunately this is the only way for Android team to enforce good practices to most manufacturers. If not, you would still see new devices coming out without usable encryption support. The older handsets will still be protected by Play Services as long as they stay mostly in Play Store and don't install random apks from the net.
Yes, planned obsolescence is an issue, especially for countries or groups with lower income. On the other hand phones get such an abuse through daily use that few of them last for 3 or more years.
http://www.phonearena.com/news/We-changed-the-LG-G3s-display...
This is planned obsolescence at its worst .. :/
(At this point, Android management seem to be thinking "What are the other alternatives, Windows 10 Mobile .. haar, haar ..")
This is more a cavalier attitude on the part of Qualcomm who do not support their own hardware for a reasonable length of time, and who do not foster open-source driver development which would at least allow the community to bring new features to older hardware in some cases (Vulkan being the prime example).
Imagine Microsoft blocked Windows 10 (or any of the next builds) from all the GPUs who don't support DirectX 12, so that the developers can write DX12 software more conveniently.
This obsolescence of multiple hundred $€Ł mobile devices inside 18 months is getting silly.
Your frustration is misdirected. The CTS and Google Play Services are the only tools at Google's disposal for inducing market changes. Perhaps manufacturers will demand longer support periods for upstream hardware, for instance.
Now they are tightening it up a bit which as a developer I support but honestly end users are being screwed, and the root cause is Google not Qualcomm in my opinion. Google could have from the start been stricter about certification if they really cared about delivering a good experience to end users and developers, rather than just sending out a shitty product quickly.
If custom ROMs will perform fine, this will bring a lot of flak towards Google.
So "most apps" will "perform fine" unless they rely on CTS guarantees. If they want to fix the inevitable crashes on third-party ROMs, they will need to perform the same API-level checks that apps needed to perform pre-Nougat. Which is the definition of "fragmentation".
The Xperia Z has a fully functional (all hardware, no major issues) Android 4.4 build a week after the 4.4 sources were released. It was the first non-Nexus with a working KitKat. Sony provided the right stuff on GitHub and their devices are very easy to develop for.
I used a root exploit to obtain permanent root on my old Z3c, but it felt kinda pointless since I couldn't install CM without unlocking the bootloader. (Yes, locked root made it possible to back up the DRM partition, but running CM without the DRM partition intact and the bootloader unlocked meant living with sub-optimal camera performance, so that was a non-starter for me too.)
So yes, Sony's devices are "easy to develop for", if you don't mind living with crippled hardware features (permanently, in the case of the Z5) once you unlock the device.
They ship capable camera sensors on their devices and are outperformed by other vendors who use their same sensors, but don't suck at image processing.