The Successful Use of ADB Drivers, to Enable Automation of Power-Saving, on my Samsung S6 Smart-Phone

I happen to be a long-time user of this app, which exports shortcuts to the Android system, which together with this app, allow for the automation of power-saving mode, by way of .

Until recently, this phone still had on it, which meant that the power-saving app was able to toggle power-saving mode without requiring special permissions. However, since my upgrade to on the phone (), this permission is no longer granted. And so I needed to grant access to the power-saving app, to restricted settings on the phone, via .

Today was the first time I ever used the on my Linux laptop named ‘‘.

Continue reading The Successful Use of ADB Drivers, to Enable Automation of Power-Saving, on my Samsung S6 Smart-Phone

I have just received my NFC Tags.

In This Posting, I wrote that I had ordered NFC Tags from a seller in Australia, just to assure the maximum compatibility with the Android Apps named “NFC Tools” and “NFC Tasks”. Also, this exact brand of Tags (“Whiztags”) seems to have a high number of bytes stored, as far as domestically-used Tags go.

Just as a recap, I should say that Tags can store a small amount of data, which can be read by our device as we use the NFC scanning capability that must first exist in hardware. And this can be similar to how QR Codes can be used. Even though NFC Tags can easily store a small message, in practice we are more likely to store a URL, which when read back in, causes content to display which is visible openly on the Internet. Or, we can also store commands, which our own devices are supposed to carry out, when we tap our device on the Tag.

In the latter case, which I was hoping to start using eventually, it is important that the App which carries out the stored commands, in my case NFC Tasks, be 100% compatible with the App that was used to store those, in my case NFC Tools, as there is no worldwide standard for how commands or automated sequences of tasks, are to be stored. URLs, obviously, at least conform to such a standard.

Well my Tags just arrived in the mail for me. Nobody said that the shipment from Australia was supposed to be extremely fast, and in fact I believe that having purchased these at an extremely good price, pretty much ruled out that they would get shipped to me fast as well.

So now I can start experimenting with programming physically existent Tags, hopefully in a way that will make my use of my phone more practical.

I have to admit though, that before my Tags arrived, I had already started using the App named “Tasker”, along with some of its plugins, to automate and accelerate certain uses I have for my phone, without requiring any NFC Tags per se. Tasker tasks can be triggered just by tapping on an icon, or in my case, when the phone detects that it is charging wirelessly, or when I plug in my headphones…

Yet, there is a limit to how many icons I would want to have taking up space on the limited screen-space of my phone, so that I could conceivably still fine-tune what I want to use the phone for, by preparing several actual Tags, to do what Tasker can also do more or less.

One severe limitation to using NFC Tags however, is the standard fact, that the phone must be unlocked, before the Tag is tapped, before tapping the Tag can cause our phones to do anything. This is just common sense to protect the users. For example, if our phone is set up to make a card payment, by way of NFC, we would also want to make sure that not just anybody can initiate such a financial transaction, without having to unlock a locked phone first.

Well these Tags, by way of the App I installed, can tell my phone to change its settings and do various things which could undermine my security, if I had not programmed them themselves. So just as with the electronic payment card, there needs to be some sort of safeguard in place.

The NFC Tasks App offers an additional safeguard, in that its user can choose to enforce a whitelist, of tags that are authorized to give commands. I intend to use the whitelist feature as well, just so that no hypothetical interloper slips in a tag which I would not have programmed myself…



Also, there is another observation which I should add. The way the use of these Tags is popularly described, we should tap them with our phones. This would suggest that the Tags, which have an adhesive back, should be attached to a hard surface of some kind, because directly from the seller, they come as soft, thin pieces of plastic, which should not even be bent. It would also imply, that an accelerometer in the phone detects a physical tap, to trigger some NFC-realted service to start scanning for the Tag, which has no internal power source of its own.

These tags have arrived with a key-chain pendant, as advertized, that can act as a semi-hard backing, should I in fact attach one of the tags to this key-chain. I have discovered that the key-chain ornament is itself a tag of equal capacity, which can be verified by just approaching it to the phone while the app is waiting to read tags. Its stats will be displayed just as those of the softer tags. Because of that, It would be a critical error to attach another tag to the key-chain. If one did so, this would superpose two tags, and possibly make both unusable.

But the description of having to tap an NFC-related object physically, has been in error in the past. When I use my phone to make a payment for example, I only need to hold the phone in the vicinity of the store card reader, not tap it.

I have not yet been convinced, that the accelerometer in my phone triggers its NFC coil in practice. It could just as easily be, that the vicinity of one of my Tags will trigger the phone, or else – that the phone might fail to trigger for some unknown reason. If the last thing happens, I will need to troubleshoot.


(Edit : ) The “Whiztags” which I have received, store up to 924 Bytes each, in pages of 4 bytes, and were sold to me as “A package of 10, plus one bonus tag”. This essentially means that I received 11 tags for the price of 11, including the key-chain pendant. They are color-coded for easy recognition, and the one which I have just now programmed, received 120 Bytes worth of tasks from me, which are allocated as 30 pages.

The softer tags have a very thin 3M-labelled backing, which should be peeled off gently, even though the backing itself adheres strongly, to reveal a clean adhesive surface, with which they can be attached to a clean hard object.

The key-chain that was included in my deal, serves as a possible place to attach one tag in this way. (No! See above comment!)

As I suspected, a strong touching motion or impact between the tag and the phone is neither required nor desired. It is only preferable to know where the NFC coil is located on our phone, in order for the tag to be recognized and processed – within a fraction of a second. On a Samsung Galaxy S6 Phone, this sweet spot is in the middle, of the top half of the phone.

Once a tag approaches there, it is processed exactly as advertized – in my young experience. By now I have also learned: Sometimes, if an operation on a tag seems to be taking too long, the app is actually waiting for the detected tag to be distanced, which the user may still be holding to the device from a prior operation. And then, if the tag is approached anew, the requested operation only takes a fraction of a second again.


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.



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.