from the Android Security Bulletin—May 2019:
CVE-2018-11955, CVE-2018-13901, CVE-2019-2043, CVE-2019-2044,
CVE-2019-2045, CVE-2019-2046, CVE-2019-2047, CVE-2019-2051,
CVE-2019-2052, CVE-2019-2053
from the Android Security Bulletin—June 2019:
CVE-2019-2090, CVE-2019-2091, CVE-2019-2092, CVE-2019-2094,
CVE-2019-2096, CVE-2019-2097, CVE-2019-2098, CVE-2019-2099,
CVE-2019-2101, CVE-2019-2102, CVE-2019-2269, CVE-2019-2279
from the Android Security Bulletin—July 2019:
CVE-2019-2105, CVE-2019-2106, CVE-2019-2107, CVE-2019-2109,
CVE-2019-2116, CVE-2019-2117, CVE-2019-2276, CVE-2019-2305,
CVE-2019-2307, CVE-2019-2308, CVE-2019-2326, CVE-2019-2328
from the Android Security Bulletin—August 2019:
CVE-2019-2120, CVE-2019-2122, CVE-2019-2125, CVE-2019-2126,
CVE-2019-2128, CVE-2019-2129, CVE-2019-2130, CVE-2019-2131,
CVE-2019-2132, CVE-2019-2133, CVE-2019-2134, CVE-2019-2135,
CVE-2019-2136
Please report any (new) issues through the public bugtracker and upvote existing issues if you are affected. As usual, please specify the steps to reproduce, and provide as many details as possible.
Thanks, that’s a lot of CVEs I don’t have to worry about anymore.
I saw that the experimental GLES 3.0 feature propagated into this release under the developer options. Alas, my phone is encrypted so I can’t try it out. And if I have to choose, encryption is more important to me today… I hope soon I don’t have to choose anymore.
Has someone here tried the experimental OpenGL ES 3.0 support? How well does it work? What are the technical details behind this feature?
The OpenGL ES 3.0 fix is in an experimental state because we have to learn how it behaves in the field first. That’s why we don’t include it in the release notes and only communicate about it through the beta forum and the bugtracker. Using the data from the field we continue to develop the fix internally, so that we can finalize it with the next release. That includes support for encrypted devices.
Thanks for taking your time to confirm the status of this work-in-progress fix. I fully understand the current state and, for what it’s worth, it is completely within my expectation.
I deliberately asked for technical details rather than a timeline. If people can share more information about the benefits and drawbacks of this experimental feature in its current state, I will be in a better position to judge whether the final fix will be ready for broad release in a week, a month or a year. Sharing technical details will do you a service, because it allows me to manage my expectations without you giving a tentative timeline that can be misinterpreted as a promise.
Of course I will also monitor the issue report on the bugtracker, but considering I don’t intend to perform beta tests simply due to lack of time, I feel like I might be missing out on informative progress information.
Edit: Nerdy stuff ahead, for those interested!
Looks like this release ships with the same user mode Adreno drivers as the previous releases; the one taken from the Adreno GPU SDK. The build.prop file mentions this:
# Graphics: OpenGL ES
# 131072 is decimal for 0x20001 to report version 2.0
# 196608 is decimal for 0x30000 to report version 3.0
# 196609 is decimal for 0x30001 to report version 3.1
# This is handled via vendor_load_properties override in init_msm8974.cpp
# ro.opengles.version=131072
The “experimental OpenGL ES 3.0” switch in the developer settings modifies the file “/data/misc/fairphone/experimental_gles3”. My suspicion is that the mechanism used for toggling this experimental feature relies on the boot loader reading this data file and providing the kernel with a value for the ro.opengles.version property based on its contents. If the bootloader can’t read the data partition, for instance because it is encrypted, it is unable to read this settings file. That explains the current requirement of having an unencrypted device, and that means that this requirement is trivially lifted once GLES 3.0 “mode” is deemed safe enough to become the default.
One might ask themselves why this configuration file lives in the (potentially encrypted) /data partition and not elsewhere. I suspect this has everything to do with extremely stringent file system permissions dictated by Android.
As for making this optional in the first place: I get it. There might be bugs in the drivers GLES 3.0 implementation that cause unexpected regressions. FP wants to be cautious not to introduce regressions. It’s better to break Pokemon Go than to have your SystemUI crash several times a day, your phone to stop working properly when you enable night light or something similar.
Upgrades from previous 2019.05.01(?) Fairphone OS release to this via WiFi via the Updater app. Update passed without problems. Phone seems sluggish now afterwards for me as soon as I have WiFi activated. I dont use mobile data plan, only nondata GSM/whatever standard for calls. When I turn off WiFi phone seems smoother. Rebooted several times but this oddity doesnt go away. Sometimes even clicking the main side power button once to make it sleep/screensave takes several seconds, and wiping from top to bottom to see some of the settings etc is sluggish too, or until the basic keyboard app appears within text fields. Very weird.