Porting git-annex to Android will use the Android native SDK.

A hopefully small Java app will be developed, which runs the webapp daemon, and a web browser to display it.

programs to port

These will probably need to be bundled into the Android app, unless already available in the App Store.

  • ssh (native ssh needed for scp, not a client like ConnectBot)
  • rsync
  • gpg
  • git (not all git commands are needed, but core plumbing and a few like git-add are.)

GHC Android?

Android's native SDK does not use glibc. GHC's runtime links with glibc. This could be an enormous problem. Other people want to see GHC able to target Android, of course, so someone may solve it before I get stuck on it.

References:

I've heard anecdoally that ipwnstudios not only has an IPhone GHC port, but also Android. Need to get in touch with them. http://ipwnstudios.com/

Android specific features

The app should be aware of power status, and avoid expensive background jobs when low on battery or run flat out when plugged in.

The app should be aware of network status, and avoid expensive data transfers when not on wifi. This may need to be configurable.

FAT

Due to use of the fat filesystem, which doesn't do symlinks, nosymlink is probably needed.

It's a linux kernel so perhaps another option would be to create a big file and mount -o loop
Comment by https://launchpad.net/~gdr-go2 Mon May 28 18:12:10 2012
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/

Comment by http://joeyh.name/ Tue Sep 11 02:12:45 2012

/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 :-)

Comments on this page are closed.