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

 

Print Friendly, PDF & Email

My Neato Vacuuming Robot

I own a Neato XV Signature vacuuming robot.

Neato XV _1

One problem with this robot, is the fact that sometimes it does not find its way back to its charging station correctly, after completing its job of vacuuming a large part of my floor.

My main, real worry about this in the past has been, that once the Neato has recognized it is lost in some way, even though it turns off its turbine and carpet brush, it could stay powered up, with its LED blinking in the amber color, and asking for a human to help it. In theory, the robot could do this until there was no charge left in its battery, especially if the human was not at home. And because this robot runs on Linux, this would mean a crash of its O/S.

What I have recently discovered though, is that once the unit recognizes that it needs human intervention to proceed, it does not merely shut down its motors and blink its LED. In addition, this robot will go into a low-power mode, in which a human who just came home might not even notice it. And then every few minutes, it will briefly power up again, to be able to play its notification sound, and to blink its LED, to get my attention.

And in this mode, the unit has been lost for hours while I was not at home, this past Wednesday, and it did not even deplete its battery level due to this reason. All I needed to do, was reposition it slightly in front of its charging station, and tell it to proceed as normal…

This observation has increased my level of confidence in the vacuuming robot, for use when I am not home.

Dirk

 

Print Friendly, PDF & Email

NFC Tasks can use Tasker now.

Now that I do have “Tasker” installed, I have uninstalled “NFC Tasks” and reinstalled it again. And the result is, that Actions programmed by “NFC Tools” finally have the permissions required to run Tasker Tasks. When previewing Tasks, NFC Tools uses NFC Tasks as a conduit.

I recently commented about this here, at a time when NFC Tools was displaying ‘Not Enough Permissions’ when told to preview Tasks that contained Tasker Tasks as Actions.

Dirk

 

Print Friendly, PDF & Email

An important note about Tasker

One subject which I have been exploring, is the acceleration and automation of tasks on an Android device, using the app “Tasker” and perhaps by using NFC Tags later on.

Tasker allows the user to define ‘tasks’, which should be oriented around practical cycles which we go through, that may require different settings on our phones. These tasks consist of individual ‘actions’, the latter of which are put into a sequence using a GUI – or for more advanced users, using code. Tasker has 3rd-party plugins available, and one of the plugins which I like a lot is named “Secure Settings”, although the best use of Secure Settings comes to users who are rooted, which I am not.

I also have an app installed, named “NFC Tools Pro”, which goes along with a companion app named “NFC Tasks”. NFC Tools Pro can be used to program tasks into an NFC tag, while NFC Tasks would be the app that executes the tasks, when the tags are brought into range of the phone, or the phone is tapped against them.

I also have an app installed, which is named “Headset Button Controller”, with which I can define Headset Profiles, according to which buttons on headphones, that are already recognized by the Android O/S, can be programmed to perform actions which Android does not carry out by default.

These apps can be linked to each other.

Installing Headset Button Controller, also installs a plugin accessible from within Tasker. Headset Button Controller has a direct menu option to trigger Tasker tasks. NFC Tools Pro can also name a Tasker task, as one of the actions it can program into NFC Tags. This latter detail could be of advantage to some, since the number of bytes an actual Tag can store is quite limited, but an installed Tasker task can be extensive, and in theory, an NFC Tools action may only need to state one Tasker task to do everything it is supposed to do, in which case the number of bytes on the Tag consumed, is as short as that one NFC Tools action.

I am obviously going to point out something more meaningful now.

In order for NFC Tasks, or for Headset Button Controller, to be able to trigger a Tasker task, as one action of the former, It is necessary for Tasker to be installed, before the other apps are installed.

The reason for this can be explained, in how different Android apps can share data by default. Android is based on a Linux kernel, but very little else about it resembles Linux. Android assigns one username to each app. And, any username can belong to groups as they do under Linux, which can be used for access control. In some cases, such as Tasker, the specific group associated with it must have a defined GID, so that when NFC Tools or Headset Button Controller are installed, the group which belongs to Tasker can be recognized, and so that that which belongs to Tasker can be shared with the other apps.

If Tasker was installed after the other apps, the dev has left two ways in which its tasks can still be exported to the other apps:

  1. The Tasker app happens to be one which exports shortcuts for all its defined tasks. Thus, if the other apps are capable of executing shortcuts in addition to apps, those are allowed to be Tasker shortcuts.
  2. The Tasker app has a plugin which is named “App Factory”, which can be installed separately, and which can export one task at a time, in the form of an .APK Package File – i.e. an Android app – so that to execute such an app will also cause the Tasker task to be invoked, which has been packaged in that way.

In order for “App Factory” apps to be invoked, the APKs need to be ‘side-loaded’, which means that the setting can be set briefly, allowing apps to be installed from other sources than Google Play, using the generated APK Files as their source. I do know that some people would have reservations about doing so. Which is a good reason to try to arrange, installing Tasker before installing apps which will call on Tasker.

Dirk

 

Print Friendly, PDF & Email