Monday, April 22, 2013

A tale of ten Nexi - a Google Nexus classroom

This is the story of organising a classroom set of Nexus pads so that a series of workshops can be given in a number of locations. The issue is to make sure that each user, in each workshop, starts out with a pad in a clean state.

If the state required was the standard factory state there would be no problem but each workshop requires a different configuration so the problem becomes one of managing multiple Android images across multiple devices.

Clearly the keys are:
  • A recovery image program on each device
  • A USB storage device that can be moved between devices
Taking these two requirements leads quite directly to the TWRP (Team Win Recovery Project) image as this has clearly enunciated support for an external drive.

The USB device needs to have power requirements that allow it to be seen by the Nexus and this has meant that only my newest thumb drive would do.

Recovery images are quite large so the next problem is to make sure that only one copy of  each image needs to be stored. Linking between files or directories is not available in FAT32. It is availale in NTFS but TWRP cannot read NTFS. This means an ext filesystem must be used on the memory stick.

The directory structure for multiple devices backed up to a single USB drive is as shown with a cryptically named directory to identify the device and named folders within for each backup.that contain the backup files.

The simplest approach might be to have actual backup files in the directory for for one device and then symlink the other folders for the other devices to that one copy that contains the actual files. However TWRP does not handle softlinks so the problem has to be solved with hard links to the individual files. Hard links are incontrovertible in the ext file system - there is an actual inode that references the file so TWRP uses them correctly,

To summarise a structure is required where there is a single copy of each workshop's backup along with hard links from the corresponding folder for every other device.

In practice it is convenient to have a single "master device" for each workshop so the arrangement of linking is relatively complex and handled by a script.

# Identify the four devices that will be used to work on
# and backup the device image


# The current directory when running the script is the
# one named BACKUP,that is the parent of all the device
# thus $dirs will contain a list of the devices


# Make sure that at least one device has directories
# for each of the images

mkdir $master0/StockRooted
mkdir $master0/Workshop1
mkdir $master0/Workshop2
mkdir $master0/Workshop3

# $subdirs will contain the names of all the images

subdirs=$(ls $master0)

# For each device...

for dir in $dirs

# For each image...

for subdir in $subdirs

# Figure out if the actual image files are stored here

if [ "$subdir" == 'StockRooted' ] && [ "$dir" == "$master0" ]
echo "$master0 found"
if [ "$subdir" == 'Workshop1' ] && [ "$dir" == "$master1" ]
echo "$master1 found"
if [ $subdir == "Workshop2" ] && [ $dir == $master2 ]
echo "$master2 found"
if [ $subdir == "Workshop3" ] && [ $dir == $master3 ]
echo "$master3 found"

# If we get here this was *not* one of the master images
# Figure out which one it was..

case $subdir in
'StockRooted') master=$master0 ;;
'Workshop1') master=$master1 ;;
'Workshop2') master=$master2 ;;
'Workshop3') master=$master3 ;;

# Get rid of what was there and build a new directory

rm -r $dir/$subdir
mkdir $dir/$subdir

# Figure out what files are in the master image and
# hardlink to them

files=$(ls $master/$subdir)
for file in $files
ln $master/$subdir/$file $dir/$subdir/$file
chmod -R 777 *

No comments: