Project Treble (Android O)

So, Qualcomm is providing drivers for most of the hardware of our phone, but they are integrated in the ‘normal’ Linux kernel and not the Android fork, is that correct? Would that include the gpu driver and wouldn’t it be possible to backport it for the Fairphone team or something like this? :slight_smile:

Questions from a layman… :smiley:

Correct! … although I presume they are keen to start using many of these drivers when Android versions on top of new kernels start seeing the light.

Well, a GPU driver. Dubbed freedreno. Quite a cool one, supports OpenGL better than the closed-source one, and performance is mostly on-par with the closed-source driver too if I recall correctly. No OpenCL or Vulkan for now though… If you happen to be a talented developer, contributions welcome!

[quote]and wouldn’t it be possible to backport it for the Fairphone team or something like this? :slight_smile:

Questions from a layman… :smiley:
[/quote]
You mean backporting to an Android kernel? Technically there’s little to prevent this from happening, and the main developer of this driver works with 3.10/4.4 kernels used by most Android Marshmellow distributions (Fairphone seems to be stuck with 3.4 for now unfortunately) as well as with the upstream kernel. However, freedreno was written for the drm framework (don’t worry, it’s nothing to do with digital rights management), while Android 6 expects a different framework behind their Hardware Abstraction Layer. Because of this, I’m not sure whether Android 6 would play nice with Freedreno. Collabora has worked on trying to make this work. I’d recommend you ask the experts on Freenode IRC in channel ##linux-msm for the current status and roadmap.

This is a misconception: most drivers tend to be open-source. Take a look in the Fairphone Open OS kernel repository and look at the Qualcomm components for yourself. NVIDIA Tegra has their work here, including the kernel side of the GPU driver, an old Allwinner kernel with many drivers etc. etc.
The trouble exists mostly with GPU and baseband drivers, where the kernel driver is developed in lock-step with firmware and/or user-space components. Vendors don’t keep the kernel<->user-space interface (API/ABI) stable between driver releases, which causes several problems

You are right, I was not precise. There are a lot of open source drivers: unfortunately most of them are integrated in the mainline of the linux kernel, but not in the android linux kernel. So in practice, it is like if they would not exist.

Qualcomm is doing quite a good job at developing clean upstream open-source drivers. For most devices in the Fairphone’s SoC there already is an upstream open-source driver.
This work hasn’t poured back into the Android stratosphere though. I’d like to see that happen

My question is why android linux kernel and mainline linux kernel are not the same thing?
Latest android linux kernel is v4.9

Edit: I found the answer directly from an android linux kernel developer:

The interesting thing about Android’s design is how little we modified the kernel. Most embedded systems on which I have worked have made drastic changes to the kernel, only to leave user-space alone—for example, a heavily-modified “realtime” kernel but X11 for a GUI.

Android is the opposite: only minimal changes to the kernel, but a user-space wholly unlike that of any other Unix system. In fact, Android’s user-space is so different from stock Linux, you can easily say that Android is not in any way a Linux system, except for the kernel.

3 Likes

This is all a lot of “finger in the air” talk, but I reckon for GPUs there’s a historic reason. The Direct Rendering Management (DRM) framework, the current framework for open-source GPU drivers, was conceived as a replacement for user-space desktop drivers. Thus its design was geared towards use by X.org and devices that do 2D/3D rendering and display in the same hardware. In mobile SoCs, these tasks tend to be split between various components. Not to mention X.org being way too clunky for mobile use. I bet that during the start of Android development, trying to fix these problems for SoCs in existing software was too big a task. iPhone was already on the market, so it had to be done under a lot of time pressure. Instead, they built something simpler. Obviously, because it was trying to perform the same task as DRM, upstream would never accept this code. Hence Google maintained and developed it themselves.

Edit: Quite short (and boring) stream. But we could take the opportunity to discuss Tremble. :slight_smile:

I look forward to more information on Treble, which should improve the update situation on future devices.

1 Like

So Oreo it is!

Still some issues over at Google: https://www.android.com/oreo

2 Likes

This works:

My Highscore was 202.

I have to admit, the solar eclipse reference is not the worst idea they’ve had… :wink:

Edit:

Where did you find a game??? I’m clicking on the version number, but nothing happens… :confused:

My personal highlights from the “changelog”:

Install unknown apps: Hostile downloader apps can’t operate without permission; users now permit the installation of APKs per-source.

Will it finally be possible to whitelist only F-Droid for “unknown sources”?

Notification snoozing: Lets users hide notifications for a period of time, similar to Inbox snoozing.

Sounds like Peace of Mind

Wi-Fi Assistant: Auto-connects you to high quality open WiFi and secures your connection with a VPN back to Google.

Yay. Read: …and routes all your traffic via Google servers so that we know all the websites that you visit, even when you aren’t using Chrome.

7 Likes

Wifi Assistant is optional, as far as I know.

Not only websites, but servers, all internet communications. An VPN routes all internet traffic, not only web traffic (the Web being a set of protocol(s) [HTTP/S] over Internet protocols and architecture [TCP/IP, SSL, DNS]).

2 Likes

I bet it is opt-out though…!

And step by step the pace of new versions in Android is faster. It will be harder very soon to keep an Android phone, at least patched and supported. It is really upsetting.

Hmm, where do you get that conclusion from? Looking at the table in your link, before Jelly Bean, it’s often been only about 10 months between the releases, then 15month between Jelly Bean and KitKat. Since then, it’s been about a year between each release, with the release shifted from October to August with Nougat.

I’m sure Google settles with the industry standard of predictable release dates (actually set by Ubuntu, then quickly followed by Apple) of one mayor release per year and I bet it will around August next year again.

This gives developers (of apps) and manufacturers (of devices) as well as chipset manufacturers predictability and allows planning. This could help improving the update situation.

Have you read why Fairphone 2 won’t likely have Nougat? The reality is that Qualcomm doesn’t want to bother with the updates. You are supposed to change mobile phone every year. So while for the vast majority of the world is acceptable, us fairphone users is a matter of concern.

So right now KitKat is somewhat supported, but no manufacturer pushing updates, so basically is dead. In my opinion Android is on the road to be the next IE6. Massive adoption, full of bugs. Google as long as it gets our data they don’t seem to look forward long term usability of the devices. I think it will backfire eventually.

By accelerating the pace of releases, the usability of your device decreases, as manufacturers don’t like to bother with the updates, just sell you the stuff. Also, Google Apps are entangling more and more within the system. For us with FOSS Android as OS, it will become harder and harder to use Android without Google. Check safetynet, they are already blocking some apps, that won’t be available on custom roms, rooted or de-googled androids.

3 Likes

Ubuntu has two releases per year (eg. 17.04 and 17.10) and an LTS every two years (eg. 16.04, 18.04).

But yes, they are very predictable and on schedule most of the time.

3 Likes

Of course i have. But software updates per se are not the reason for obsolescence. The issue with missing software updates is very important to me and a good amount of discussions I take part are about this problem and possible solutions.

The solution is definitely not stopping upgrades, but find something to lure manufactureres into updating the devices. Furthermore, I think by putting more functionality into the (Google) Apps, that can be updated via the store, the need for hardware upgrades decreases. We might not get the latest Android Oreo Optimization or Nougat Notifications, but Chrome or Gmail on our Fairphone (if we use Google) is as secure and fast and feature rich as on the latest and greatest phones.

I am amweb developer and I cannot tell you how happy I am that Google decoupled Chrome from the OS!

2 Likes

Yeah, but at the same time the AOSP core apps don’t get updates anymore. AOSP mail sucks, the browser too, etc. Google is basically suffocating Android in favour of Google Play Services. Also see this related article (from 2013):

5 Likes

Yes, that is true, and I had no intention to debate that. My point was: That Google does this, whatever you think about it, is good for people not getting the updates to the core OS from their manufacturer.

(If the use Google services.)

Project Treble solves the OS update issue, but it does not do anything about kernel vulnerabilities, is that right?

1 Like

I would rather say: Tries to improve the update situation, not solves ;-). And as far as I understood, your are right, that kernel vulnerabilities could still be an issue.