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:
- http://stackoverflow.com/questions/5151858/running-a-haskell-program-on-the-android-os
- http://www.reddit.com/r/haskell/comments/ful84/haskell_on_android/
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.
mount
requires root and you'll have still the 4gb limit for your image by FAT. some phones (e.g. galaxy nexus) already useext4
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:well, that isn't really static. tell the linker to build a static binary (those are arguments to
ld
):now, get this (quite big) binary into the normal android environment, using
adb
,SSHDroid
or whatever:looking in the source of
System.IO
it seems like aniconv
issue. So, there's still some dynamic dependency in there... sighThanks 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: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:
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.