I see Android 7.1.1 as a significant improvement over 5.x .

In Android 7.1 , Google seems to have taken an aggressive approach to rectifying this problem and this problem.

Not only do newer versions of Android give users control over granting each permission to an app that requests it, thus slowing down privilege escalation attacks that have been possible in the past. But Android 7.1 actually rolls back permissions, which have been granted in the past. When we upgrade, the apps are optimized in such a way that many of their permissions default to Not Granted, until an effort is made by the user to Grant Them.

Further, since version 6.0.1 , Android has a feature called Doze. What it seems to do is cancel alarms which apps had set, to wake themselves again in the background. It cuts down significantly on the battery consumption of a fully up-to-date Google Pixel C.

Unfortunately, this also interferes with how the email apps Kaiten and K-9 work, which try to poll the email servers at regular, user-configured intervals, but which eventually stall in their older way of doing so, instead displaying the message ‘Sync Disabled’. On my own Pixel C, I have had to whitelist the Kaiten app, to exclude it from Battery Optimization manually, so that now it is fetching emails from the server again.

Continue reading I see Android 7.1.1 as a significant improvement over 5.x .

Android Permissions Control

One fact which I had written about before, was that Android differs from Linux, in that under Android, every installed app has its own username. Also, because different users installed a different set of apps in different order, the UID – an actual number – for any given username will be different from one device to the next. And then I also wrote, that a username belonging to a group or not so, can be used to manage access control, just like under Linux.

There is a reason for which things are not so simple with Android. Most Android apps are written in a language named “Dalvik”, the source code of which has syntax identical to “Java”, and which must be compiled into “Bytecode”. The bytecode in turn runs on a bytecode interpreter, which is also referred to as a Virtual Machine.

The reason for which this affects permissions, is because as far as the kernel can see, this VM itself runs under one username. This is similar to how a Java VM would run under one username. And so a much more complex security model is put in place by the VM itself, because presumably this VM’s username has far-reaching capabilities on the device.

The actual use of groups to control access under Android is simpler, and applies at first glance to processes which have been compiled with the ‘NDK’ – with the “Native Development Kit” – and which therefore run directly, say from C++ source code.

Further, the Dalvik VM is capable of reading the permissions of actual files, and is capable of applying its own security model, in a way that takes the permission bits into account, that have been assigned to the files by the Linux kernel. So for most purposes, the security model on the VM is more important than the actual permission bits, as assigned and implemented by the kernel, because most Android source code is effectively written in a Java-like language.

Dirk