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

 

A Realization About Samsung S6 Power Saving Access

In a previous posting, I had remarked that the (famous) “Tasker” app has a 3rd-party plugin named “Secure Settings”, which has a sub-section named “Samsung ROM”, under which there is a function named “Enable / Disable Power Saving”.

The general context of this is, that Tasker is a task Acceleration / Automation tool, in which each Task is defined as a sequence of Actions, many of which are built-in, but some of which are Actions defined by 3rd-party plugins, such as by ‘Secure Settings’. Hence, it was a goal of mine to insert the Action into a Tasker Task, which would turn the Power Saving Mode on, on my “Samsung Galaxy S6″ phone.

I am Not Rooted.

This failed every time, and at first I thought the reason would be, that the author of ‘Secure Settings’ had failed to keep his module up-to-date with the latest Android Lollipop version, which my S6 is running.

But then another observation came to my attention.

The app “NFC Tools Pro”, and its companion, “NFC Tasks”, is also supposed to support, that an NFC Tag should enable Power Saving Mode on a Samsung Phone, when we tap the Tag. ‘NFC Tools Pro’ additionally has a mode in which it executes its Task as a test, before that Task has even been programmed into a Tag. And when I ran the test, this app was also unable to switch on Power Saving Mode.

In both cases the behavior is identical, in that the Action returns as a ‘success’ immediately (even though when I Enable Power Saving manually, it takes several seconds for this setting to kick in), but in that Power Saving Mode is not enabled – even later.

And so an inference which I am making about this feature, is that indeed the app developers are not up-to-date with the latest Samsung API – Only Because on the latest phones, one needs to be rooted in order for this command to work (!)

And so what I ended up doing both as an intended, future NFC Tag Task, and as a present Tasker Task, was simply to script a pop-up to appear, which states “Suggest to Enable (or Disable) Power Saving Mode Now.” It is a shame, that the whole procedure cannot be 100% automated, but I guess that Samsung has been very conscientious in its efforts to increase security. And denying ‘any old app’ permission to fiddle with the power settings in general, could be a step towards greater security.

Dirk