It's a linux kernel so perhaps another option would be to create a big file and mount -o loop

mount requires root and you'll have still the 4gb limit for your image by FAT. some phones (e.g. galaxy nexus) already use ext4 for /sdcard though.

I played around a bit with GHC and Android today. It isn't really a result, but maybe useful for someone out there.

I have a Debian chroot environment on my Android device (howto: http://www.saurik.com/id/10/). In the Debian box:

$ cat arm.hs
main = do
  putStrLn "Hello ARM"
$ ghc -static --make arm.hs
Linking arm ...
$ ldd arm
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40233000)
libm.so.6 => /lib/libm.so.6 (0x400c8000)
libffi.so.5 => /usr/lib/libffi.so.5 (0x401b1000)
librt.so.1 => /lib/librt.so.1 (0x40171000)
libdl.so.2 => /lib/libdl.so.2 (0x40180000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4018b000)
libc.so.6 => /lib/libc.so.6 (0x40282000)
/lib/ld-linux.so.3 (0x400a2000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4007e000)

well, that isn't really static. tell the linker to build a static binary (those are arguments to ld):

$ ghc --make arm.hs -optl-static -optl-pthread
[1 of 1] Compiling Main             ( arm.hs, arm.o )
Linking arm ...
$ file arm
arm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, not stripped
$ ldd arm
    not a dynamic executable
$ ./arm
Hello ARM

now, get this (quite big) binary into the normal android environment, using adb, SSHDroid or whatever:

% cd /data/local/tmp # assuming destination of file transfer
% ./arm
arm: mkTextEncoding: invalid argument (Invalid argument)

looking in the source of System.IO it seems like an iconv issue. So, there's still some dynamic dependency in there... sigh

Thanks Bernard, that's really massively useful. It makes sense -- statically building with libc should work, the Android kernel is still Linux after all.

To get past the iconv problem, I think all you need is part of the locales package from your linux system installed on the Android. Probably just a few of the data files from /usr/share/i18n/charmaps/

/usr/share/i18n/ does not exists on my Debian ARM system :/

however, strace ./arm in the debian chroot reveals that some files from /usr/lib/gconv/ are loaded:

[...]
open("/usr/lib/gconv/UTF-32.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\4\4\0\0004\0\0\0"..., 512) = 512
[...]

full log: http://wien.tomnetworks.com/strace_arm. Unfortunately, I don't have strace in the android userland for comparison.

Just copying the related gconv files didn't work. I don't have so much time at the moment, I'll investigate further in some days or so.

At least, output using error :: String -> a does work :-)

Just so this does not get lost: For better or for worse, the vanilla Android devices stopped shipping with micro-SD support in 2011 (or 2010 if the Nexus S does not support them either; on sketchy GPRS so not googling around). Most higher-end Android devices ship with at least 8 GiB of on-board Flash storage, some even go up to 64 GiB.

IMHO, this would make it viable to first get git-annex working on Android without regard for FAT.

The obvious advantage is that porting should be easier and quicker.

The obvious downside is that this may mean revisiting some parts of the code later.

-- Richard

Actually, this is something that would be ideal for a poll:

Should FAT-based Android repos be implemented:

• Immediately
• After the initial release of the Android app is working
• Before the kickstarter ends
• Not at all

Also, as another data point, the FAT-based SD card can be mounted as USB storage by any computer an Android device is connected to whereas the EXT4-based root FS can only be accessed via MTP.

I use Terminal IDE on android, which is 'sort of a shell environment'.

It has bash, git, dropbear ssh, and vim. It is a bit limited, but it does feel like a linux shell.

I'd like to have my phone sync a bunch of files when I'm at home and when I get to work, have them synced to my work machine, deleted off my phone and when I get home, also deleted off my home machine.

This will allow incremental backups to a local folder at home and I can then "mule" my files, sneaker-net style, to work with zero user intervention. It only works if events can be triggered or I can combine a triggering app with a special android intent for both ends of my trip.