Tuesday, March 22, 2016

Torrenting on Android: Squeezing Your Left-over Mobile Data

Many of you may be using mobile data subscriptions with daily quotas, resetting usually at midnight. While heavy users may drain the quota easily, light surfers (like myself) may see several megabytes of data being unclaimed each day.

Utilizing such excess data for torrents is a common trick used by movie fans and many others. Currently good torrent clients are available for almost every platform, including Android smartphones. Flud is one such great Android torrent client in widespread use. So if you have an Android phone with a data subscription, there's no need to keep your computer running overnight as the phone is fully capable of catering to your torrent needs.

However, a naturally arising problem is at what time the torrent client should be launched, and when it should be stopped. The problem is that one's data usage pattern is variable, so you cannot exactly decide for how long you should allow it to run. As the quota usually resets at midnight, manually launching the client at, say, 11 PM and closing it at midnight is also not very intuitive, unless you're nocturnal and you have a really good memory.

My approach to solve the issue goes as follows:

Revising our requirements:

  1. start the torrent client at a late hour
  2. stop the client (or disable data) as soon as the quota is hit
  3. shut down the client right before midnight so as not to ruin the quota for the next day

The second requirement is fairly easy to satisfy, using a custom quota app like Data Lock (or the data limit option of the native data usage monitor, if you're fortunate enough to have a daily limit option there). With Data Lock, all you have to do is to add a data plan of the expected volume, set the reset time (e.g. daily at 00:00), and engage the options "Disable data on reaching plan limit" and "Enable data on plan renewal" so as to eliminate all manual work of the enable-disable cycle.

For the first requirement, you can use any of the various task scheduler apps. Tasker is the undisputed leader, so we'll go with it. Just create a new time-based profile for 11 PM, and add a "launch app" task for Flud under it.

All sounds fine, but how to set up the third requirement? I tried a few approaches, but to no avail:

  • the native "kill app" option on Tasker does not work for Flud
  • the TaskKill Tasker plugin does close Flud, but only under the "force stop" options (which is unacceptable as Flud is a torrenr client and requires time to quit gracefully)
  • quitting by automating menu commands (Menu > Shutdown) via AutoInput does not work on older Android versions (e.g. on 4.2.2 which is what I have)

Having a look at the LogCat output, however, we see that an Intent is broadcast when you quit the Flud app via the menu:

V/ActivityManager( 561): Broadcast: Intent { act=com.delphicoder.flud.SHUTDOWN flg=0x10 } ordered=false userid=0 callerApp=ProcessRecord{43470a20 25617:com.delphicoder.flud/u0a10110}

Reproducing this broadcast does indeed close the app! What we need is a new Tasker profile for, say, 11.59 PM, triggering a task that sends an com.delphicoder.flud.SHUTDOWN intent to the broadcast receiver (other "target" options do not seem to produce the intended result).

So, all that remains now is putting together the ingredients:

  • Flud with some torrents added, having been shut down while the torrents are active
  • Data Lock (or another data limit app), with a proper data profile
  • Tasker, with the two profiles in place for starting and stopping Flud at appropriate times

Set them up, sit back, and enjoy your torrents at no extra cost!

Did Android SDK Update Ruin Your ADT? Don't Panic!

Despite the new Android Studio hype, many are still sticking to the old Eclipse+ADT (Android Developer Tools) set-up. However, despite its maturity, ADT can still cause numerous headaches to an average Android developer. One notable case is the compatibility issue that arises when you update the Android SDK without first installing the corresponding ADT updates. In several scenarios described on StackOverflow and other programmer forums, some devs have been so messed up with this issue that they have finally reinstalled everything from scratch.

Recently I too stumbled into the same issue when I updated my SDK to v24. My ADT is fairly old (v22.6.2) but had been serving me well until the said SDK update. After the update, Eclipse started complaining "The Android SDK requires Android Developer Toolkit version 23.0.0 or above", the common symptom of a streak of troubles. Adding the update URLs as suggested in most forums did not solve the issue, and I didn't want to lose the SDK update either.

Looking back at the error message:

The Android SDK requires Android Developer Toolkit version 23.0.0 or above

23.0.0... Hmm... Looks like the SDK explicitly demands the exact version 23.0.0. So the string 23.0.0 would probably be lying around somewhere among the updated SDK files.

Easiest way to find out?

cd /usr/lib/sdk
grep -rI "23\.0\.0"

Gotcha!

tools/lib/plugin.prop

File says

plugin.version=23.0.0
and that's the only occurrence.

Let's try changing it as

plugin.version=22.6.2
and restarting Eclipse.

Damn, the error is gone! So, is that it?

Not so fast... Something's still wrong, and I can't run any apps yet.

When I try to open the DDMS perspective, I see the culprit:

[2016-02-27 19:33:33 - DDMS] DDMS files not found: /usr/lib/sdk/tools/hprof-conv

So where is hprof-conv? This is one case where Google has moved one of its tools away from its prior location,

In Linux-based systems, fixing this is pretty easy; I'll just create a symlink at tools/hprof-conv pointing to platform-tools/hprof-conv:

usr/lib/sdk/tools$ ln -s ../platform-tools/hprof-conv hprof-conv

Relaunch Eclipse, and you're all set for your next Android adventure with the latest SDK!

Caution: These steps were formulated specifically for ADT v22.6.2 and the Android SDK v24 update. Depending on the versions you have, you may need to go through more or less work, or not be able to get things running at all.