Android phones run full Linux kernels

Google chats about details about Android 8.0, part 2

Google has a lot to say about Android 8.0 and Android in general
Logos: Google, graphics / assembly: teltarif.de In the first part, some important things about the upcoming Android update were already addressed. Among other things, what Project Treble is all about, including its weaknesses, what Google has in mind with SafetyNet and Root users - or not - and why a Themes engine is such a big challenge.

However, that was only a fraction of what the developers at Google were talking about. There is a lot more that is of interest, but was not included in the last article due to lack of space.

Optics vs. AMOLED

Google has a lot to say about Android 8.0 and Android in general
Logos: Google, graphics / assembly: teltarif.de With the exception of Samsung, comparatively few manufacturers use AMOLED displays in their devices, including Google with the current Pixel models. Now the developers were faced with the question of whether the navigation bar should not shine in the same colors as the status bar. Particularly with a view to OLED / AMOLED, a well-considered decision is required in order not to risk lightly burned-in pixels.

This point and the fact that too many colors behind the display buttons distract too much from the actual app, has resulted in the navigation bar remaining black without further ado. Especially since not every app colors the status bar, which in turn speaks against the solution of adapting the navigation bar to the status bar. The risk of a burn-in of individual pixels, in the worst case even with a color gradient, would best be dealt with with a gray bar, but Google does not find this to be an ideal solution either.

Therefore, the team of Android developers will still have some internal discussions about what would be a good way to spice up the navigation bar in future versions.

Dark mode

The dark mode, which is used several times in developer previews, belongs to a certain extent to the themes engine, as Alan Viverette, Technical Lead Manager of the Support Library team at Google, mentioned.

In short, a dark mode would have meant double the graphics work, since the entire system including the ecosystem would have to be adapted. A job that is simply too time-consuming - even if a time-controlled change of the material design surface was a very popular gimmick within Google.

The bottom line is that profound changes are required in various core components of Android and the app framework, so that neither the themes engine nor a simple dark mode is officially part of Android 8.0.

Doze mode vs. app developer

With Android 6.0 Marshmallow, Google introduced the so-called Doze mode for the first time, which is supposed to save significant energy when idling. With Android 7.0 Nougat this mode has been improved and with Android 8.0 the background limits are added. This naturally begs the question, why do some app developers try to bypass Doze mode forcefully, to which the team did not provide an answer.

With Marshmallow, Google simply wanted to reduce energy consumption in standby mode and experimented with how apps could be used in this state. The collected data was ultimately incorporated into Nougat's improved Doze mode, and its results in turn result in the background limitations. "Intent Broadcast" is part of that, and with Android 8.0, the ability for developers to use new broadcasts through their apps in Doze mode will be severely limited.

In short, one of the biggest causes of RAM full is invoking background services. In some cases, services are started that a user does not need at all and ultimately fill up the RAM, let the garbage collector run more often and thus make the device feel slower. With the background limitations, this behavior of apps is also targeted and a corresponding API interface is offered for some unnecessary background services. However, whether developers make use of it or try to find a Frickel solution around it is a completely different question, not to mention the whitelist implementations of the OEM manufacturers.

Diane Hackborn, Android Framework Engineer at Google, even regards background limitations as the most radical change in the app model since Android 1.0 and thus virtually in the entire history of Android.

Kernel updates for older devices

Not directly related to Android 8.0 itself is the question of why older devices only rarely or not at all receive significantly newer kernel versions. Tim Urray, Technical Lead Manager for Android Security, explains the hassle for OEM manufacturers. Each kernel for the individual devices or processors used has its own infrastructure for building and chip-specific drivers / patches, which would take even very talented kernel developers months to adapt even the smallest changes for the respective processor. This is why there are comparatively seldom significant kernel updates that have been adapted down to the last detail. In particular, constant testing with every small change to the source code costs time, which in turn costs companies, above all, money.

On the other hand, it does the user comparatively little benefit if the Linux kernel makes the jump from version 3.18 to version 4.4, for example. The performance experienced in everyday life will not change that much, says Tim Murray. However, if there are actually usable functions in newer kernel versions, Google will try to implement them in the best possible way as part of a backport. However, updates in the area of ​​security are constantly implemented by Google, so that the Linux kernel in the current Android versions is as safe as possible from attackers.

Faster file system for flash memory

A very interesting question is whether Google will officially raise the Flash-Friendly File System (F2FS) to the standard for Android in the foreseeable future. The answer from Romain Guy, Technical Lead Manager for the Android graphics team, is short. In short, it is a promising development, but one that still has to nibble in the area of ​​hardware encryption. For file-based encryption, as is mostly used with Android, Ext4 is still ahead of the game as a file system.

However, F2FS proves to be considerably more powerful compared to Ext4 and offers other advantages as it was specially developed for Flash and NAND storage. Therefore, Google will continue to experiment with F2FS and will likely make it their preferred filesystem at some point. Until then, however, it remains purely optional.

In a separate article we will explain to you which devices can be expected to be updated to Android 8.0.