HOME  |  GIT Overview  |  Script-Archive: (docs) : (wiki) : (git)  |  Android: (articles) : (files)  |  ...

Coping with Android


Also see the Android directory of the script-archive.

Besides some scripts, this directory contains a one-time snapshot of my working Android environment intended to complement the articles below.

The snapshot contains scripts for the Android shell, a collection of static armel binaries, the tree structure of the chroot on the Galaxy Note, as well as scripts and configuration files used for monitoring, backup, etc from a remote Linux server via cron.

The articles are licensed GPL-style under the terms of the most recent creative commons CC-BY-SA license.

01 - Setting up the Samsung Galaxy Note as a Unix Box

(or at least as much as we can get away with, given Google's Linux kernel patches and dumbed-down kernel configuration)

This article demonstrates a sane setup of GNU/Linux on an ordinary last-year's 1-GB-RAM DUAL-CORE PC (also known as Samsung Galaxy Note).

The Note is often wrongly accused to be a less powerful mere internet or media tablet or a traditional-style smartphone. Some even combine both insults and call it a phablet. VOIP, some cheap prehistoric gsm feature plus small weight seem to be too distracting to perceive the similarity to PC specifications.

The only difference to the best of the current crop of tablets is the display density. Excluding weight as well as 64bit and virtualization CPU features, a comparison in hardware specifications of Note vs PC doesn't show anything of interest lacking on the Note:

So the only remaining interesting difference is in software, and in the encoded usage / user interface assumptions. And I consider some of Google's assumptions (derived from RAM-starved PDAs of yore) to be already obsolete in the face of current hardware.

Remember Moore's Law - modern real smartphones just aren't. Just phones that is. And restricting usability just also isn't. Smart that is.

So for now, let's just prove Google wrong, and use the Galaxy Note for more than just SMS or USB storage for taking a few of your files along.

Let's escape from Google's dumb-down getting-in-your-workflow single-task Android usage mode, and put the GNU back in GNU/Linux.

You gain use of a full Desktop everywhere you are, while neither going full cloud (with all associated disadvantages) nor having to lug around a 20-times-heavier laptop.

In addition, at least your non-graphical apps will be uptodate with security and bug fix support for many years to come, regardless of the level of vendor/channel delays, (non)-support, and early obsoleting suffered by unmodified Android devices.


The first part investigates the device and contains some notes of available resources and rooting.

The second part describes setting up enough of a real Unix user space to actually permit proper use of the Android shell.

Building on these basics, the third part looks at creating a full customized Linux setup for the road: Create a Desktop-size DEBIAN armel CHROOT setup and make that a first class citizen in any LAN you encounter (ssh, file serving and filesystem mounting, with some automation for the home WLAN).

The final step is running a local X11 Desktop on the Note, using the chroot's vncserver or Xvnc (market: Xvnc). To access, either use the local display of the Note or any PC with a vncviewer.

The Note and this setup is more than enough for normal OpenOffice or LibreOffice text editing, programming or some light web browsing in X11.

Note that Canonical offers this simple idea to hardware makers as part of Canonical's take on chroot computing: "In every dual-core phone, there's a PC trying to get out." - Well said, Canonical!

The first article: "Setting up the Samsung Galaxy Note as a Unix Box".

For an overview of alternative approaches, see the companion article 1b - Setup Alternatives, which takes a look at alternate package feeds like OPTWARE/ipkg, build environments for porting like OpenEmbedded. It also lists some (still incomplete) native-X11 / native kernel hacks, which permit use of a fully non-chroot package-management-controlled user-space.

Most of which would easier, unnecessary, or for idle curiosity if Android would use proper package management for system apps instead of the current big-binary-blob update approach. Which is suitable for a pre-2000's VHS video recorder's firmware. But embedded hardware nowadays doesn't mesh well with support concepts already ailing when those non-networked fossils where Rocket science.


02 - (Ab)Using TWLAUNCHER: Helping Android Cope with Moore's Law

I cannot help but assume that Android devices were never expected to grow up and achieve (virtual) Desktop size, considering user interface, application presentation and some sneak peeks into the framework source. Maybe Google wanted to be polite and offer the user to maybe install upto a dozen apps of his own.

But a modern Android runs on different hardware: Desktop-size displays (1280x800) coupled with Desktop-size RAM (1GB) and Flash memory sizes already suitable for a full-sized Linux or Windows "root" installation. Available space and possibilities tend to be used, so we have standard Android setups using 180 apps as part of the rom blob with maybe 200 to 300 additional installs from the user.

Severe growth pains and unsuitable design decisions are e.g. visible in system_server and Samsung's TouchViz twlauncher: Confront them with more than a dozen or two sdcard application "installs" - twlauncher gets unstable, but system_server timeouts and the phone does a soft reboot loop (only recoverable by adb shell and doing uninstalls of most of the sdcard apps). The framework also regularly forgets assigned application numbers (abused unix user id/group id) as logged in the shamefully hidden /data/system/uiderrors.txt. If you've an app that suddenly only force-closes on startup, this is the likely reason as affected apps are incapable of accessing their own files and databases.

I wonder what Google does the non-rooted user want to do? Probably sending the device in to service, and buy a second device to survive until the slow (off-shore) service returns the (un)repaired device?

Once again, the only usable, moderately up-to-date/secure Android device is a non-provider-locked rooted one (this specifically excludes signed-bootloader-crippled models from the likes of Motorola, e.g. the early-on abandoned Motorola Milestone, a disastrous mess in every area but hardware).

The second article "(Ab)Using TWLAUNCHER" describes an approach to use the default app launcher of the Note to organize hundreds of apps and then to reuse that data outside of the application, maybe in conjunction with backup files created by titanium backup to do some apk management after e.g. flashing a new ROM.

I also list most of my app selection and their folders/categories, so you might call this article also a suggestion list for android apps.

A similar approach is possible for anything that either categorizes applications or for any launcher application that offers a folder concept. Of course, if those applications would just use symlinks or similar filesystem-level concepts, the annoying database extraction step wouldn't be required at all, while offering the user on the Android transparent access and editing capability by just using a file browser.


03 - Android in Context: Security, Privacy, Permissions, Restrictions

A look at the privacy and security implications of smartphones, using the Galaxy Note as an example. Also some notes on (not) empowering users.

For technical content, this sections mentions the FW firewall script from the previous article, checks recurring netstat output for network connectivity and takes a quick look at LBE, Permissions-Denied (both market) and Android permissions/intents/receivers. A short peek is also directed at the gingerbread core of the framework's security and package management and the packages.xml/sdcard/uiderr.txt symptoms of its scaling problems.

Again, part of the problem is misunderstanding and misrepresenting desktop-class portable computers as the magical-but-dumb physical gadget traditionally called either PDA or smartphone. The inherent capabilities of the hardware however are desktop-class and furthermore, the device is an always connected internet computer, with all the inherent security issues and third-party cravings for access to device and user profiling data.

Note that the issues raised are generic to all newer smartphones and tablets.

The third article "Android in Context: Security, Privacy, Permissions, Restrictions".


HOME  |  GIT Overview  |  Script-Archive: (docs) : (wiki) : (git)  |  Android: (articles) (files)  |  ...

jakobi(at)acm.org, 2012-01 - 2012-03