How to make Tasker launch Google Play Music.

There exists an automation app for Android, which is named “Tasker”, and which can even be useful for non-rooted phones. Tasker has a plethora of Actions which it can sequence, in the definitions of Tasks which the user gives it, and the actions fall into many categories. Further, there exist plugins to Tasker, which add even more categories of choreographed actions which Tasker can run. And, Tasker has its own built-in Music Player.

But, several people have asked how it is possible to control the playback of music from other media players than the built-in one, most notably “Google Play Music”. One reason is the fact, that if we ever get into a confused state with our phone, we would like to take control of the process in spite of Human Error which always happens, and then to have all our widgets and controllers focused on one app, can be an immense benefit.

One way in which some people have recommend that we could control Google Play Music from Tasker, was by selecting an ‘Activity’ module, which allows the user to specify an app, and to specify an Intent as well. This is more or less what programmers would do, and involves some intricate spelling of syntax in fact. The fact that Tasker has an Activity module, which even displays a drop-down list of available Intents, does not help us much with Play Music however. I do not know if other people have had luck with that route, but I did not after some intense efforts today.

What worked for me, was to go into the Tasker ‘Media’ category, which offers a ‘Media Control’ Action, into which we can enter, which Media Player we would like to use, and which Simulated Media Button command we would like to send it. This is more of a GUI-oriented approach, and works much better for me.

This playing with Tasker is part of an effort I am making, to streamline the process by which I get out the door in the morning, which I will eventually be trying to accelerate with NFC Tags. But since the Tasks which I have waiting for my tags, when those arrive, often use such tricks as to invoke Tasker in the background, this suggests the question of why tags are even of any benefit, since by now I have a custom Notification Icon, which just launches a Tasker task, which sets me up almost as quickly.

One quirky answer to that for the moment is, that there is a bug in how Tasker would try to enable Power Saving Mode on my Samsung phone. That module just does not work for the moment, while I have every reason to expect that the “NFC Tasks” app will be able to accomplish that part of the daily ritual successfully. So that part of my automation is not implemented yet.



Android App Permissions Dialog

Most Android users are at least vaguely aware, that every time we install or update an app, we’re shown a dialog with a list of permissions the app is requesting on our mobile device. We can either Allow or Deny this request.

What people should be aware of as well, is that by default, Android did not allow us to Accept or Decline each permission on its own. We were shown the whole list, and would then have to either Accept or Decline the entire list, and in the latter case, the app would not install, or the update would not take place.

This was a rather powerless feature, because when we declined an update, Google Play would just come back within short order, and offer the same update again. Also, there was no way to opt out of updating for one specific app. So we would then either be obliged to accept the update at a later time, or to uninstall the app.

This was the status-quo up to and including “Android Lollipop”. The Android version that came after Lollipop, and which is the current version, is called “Marshmallow”. And the main, key improvement which Marshmallow offers, is control by the user, for each individual permission the app is asking for. With Marshmallow, the user is no longer obliged either to accept the entire list of permissions or to reject it. He can grant or deny any specific permission, and then still install the update, which gets rid of the messages for that update.

One reason fw this is important, is the possibility of a “Privilege Escalation”, which is also a known form of cyber-attack. Privilege Escalation means, that an already-installed app can ask for progressively more permissions during each update, which users often don’t pay strict attention to, so that after several updates, the app has a dangerous collection of them on our device.

Granted, most of the time the apps need a large number of permissions for innocuous purposes, or maybe because they’re just not programmed well enough, to work without those. But the potential exists for too liberal a set of permissions eventually to compromise our privacy online, or even our online security.

This is why, regardless of whether we have Marshmallow or not, we should in fact be examining the requested permissions each time, before we simply grant them.

Having said that, I don’t have Android Marshmallow yet. This is secondhand information, from a friend of mine who is in the know, and who has Marshmallow on at least one of his devices.



Living in a World of both New And Old Computers

One of the ironies that I notice in my life, is that even though I own both modern Android devices, and older Linux devices, I still get a lot of satisfaction out of ‘tinkering’ with my Linux devices.

I’d say that for most purposes, the more modern – or post-modern – mobile devices truly have become more useful on a practical level. But there are still certain types of tasks which need to be left to the older technologies. And one of the latter would be, to dedicate a machine to act as the host for server-programs, i.e. to use a machine as a server.

Further, even though I’ve had an intense interest in the past in CGI – in Computer Generated Images – I would not say I’m avidly into computer-gaming. I do hold a few player-licenses to video games. But if I was intensely into playing video games, then the Windows machines would start to become indispensable.

Linux just seems to be an ideal platform for servers, but is also surprisingly efficient at multimedia work. And, Linux can be a powerful platform to run CGI. It’s just that Linux gaming is not up to par, mainly for financial reasons. Firstly, the way Debian Linux works tends not to play well, with DRM. And games are after all sold for profit. Secondly, there isn’t a sufficiently high percentage of users based on Linux, really to make it worth the while of major gaming companies.

There have been various ways to integrate some DRM’ed software with Linux constraints, even though Linux is better-associated with its open-source background.