Many Android devices come with storage configurations that are surprising to end-users. A product that is advertised as having 32 gigabytes of memory may in fact turn out to have much less available in terms of installing applications.

This is because of the way that older or cheaper Android devices partition their memory. A typical experience is to find that a system partition (the operating system and integrated bloatware), an application (where the applications install to) and an SD card partition (for data). In terms of the associated hardware, the system partition (2 GB in the linked example) is "real" memory and thus expensive. The application partition and the "SD card" (NAND Flash RAM) is used by photos, videos, and user data. An external SD card (e.g., a Micro SD card) is one which the user can physically remove.

When the application partition is full, well-designed third-party applications can be moved (Settings, Storage, Apps, move to SD card or move to Internal Storage or similar). However not all applications are designed to do this, leaving the user in a bit of a bind. So a little bit of developer-style tweaking is required.

Firstly, enable USB debugging on the 'phone. This process is silly to the point of being childish; (Settings, About Device, and tap on the Build Number several times). It will provide a prompt "You are now a developer!", ya really.

After that, enable USB debugging. A new menu item, Developer Options is available under Settings. This has a path to USB Debugging (Settings, Developer Options, USB Debugging) and ensure that MTP connections are established.

Once this is done, on the computer system download the Android SDK and update it (./android update sdk --no-ui).

Next determine the vendor ID by running lsusb and creating a udev rule and reload the rules.


# lsusb
Bus 004 Device 079: ID 2207:0011

(snip).

The above is the relevant device; informative isn't it? Actually, it's the ID that's important, the first four numbers are the vendor and the second four the device. You need to add the vendor ID to your udev rules.


# nano /etc/udev/rules.d/51-android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="2207", MODE="0666", GROUP="plugdev"

(Check permissions for the group).


udevadm control --reload-rules


Initially an attempt was made with Debian Mint; the server was started but it simply failed to recognise the device.


# adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
#adb devices


Nothing! After much awful playing around, changing to even an old version of CentOS generated a different bug.


#adb
adb: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory


Whilst 32 and 64 bit libraries were installed, a little further push was required:


# yum install ncurses-libs.i686 libstdc++.i686 libgcc.i686


Ready to go, lsusb was run, the udev rules were written, and the server was restarted (all as above), and the device was detected:


# adb devices
List of devices attached
8AKBAM4YLS device


Now for the developer tweak; establishing the default partition used for installations (we already know that, but it's good to check) and setting a new one, the external SD card.


# adb shell pm get-install-location
0[auto]
./adb shell pm set-install-location 2


Now many applications that were previous "stuck" on the application partition could be moved to the SD card - but not all of them. Fixing those is for another post.