Develop Reference

Using repo sync for building android GPL-compliant?

the android sourcecode is pulled with repo sync, but as it consists of many repos, I can't think of a way how to create an exact same binary without kind of "exporting" the current state in a list with the repos with the last synced commit. But this is needed for it being GPL-compliant.
Or, as only the Linux-kernel is under GPL, ain't that needed?
Thanks for any answers!

Android Eclipse - How to share an assets folder?

I have a number of different Android applications building in Eclipse / ADT that share common code and assets. Sharing the common source code folder is easy as I can use Link Source in the Build Path set-up. This works great.
These programs also share the content that's in the assets folder. At the moment I'm duplicating, which is a bit inelegant and error-prone.
Is it trivially possible to tell Eclipse / ADT to use a common assets folder in a similar way that it is trivial to have it share a source code folder? I can't find any similar option or tool.
Notes:
I am not looking for a 'library' solution (indeed that seems
fraught with issues anyway, and I did try that previously and hit
issues like this one). In any case that's less relevant for
assets, and I'm looking for simplicity.
It doesn't matter if the shared assets folder has to contain a
superset of the needs of all the applications.
Assets. Not "resources".
I'm using ADT version 22.2
For many complex reasons, symbolically linking the folders will not suffice. (You do not want to know the details. You'd never believe them anyway.)

Sharing the common source code folder is easy as I can use Link Source in the Build Path set-up
I would not count on that working over the long haul.
At the moment I'm duplicating, which is a bit inelegant and error-prone.
Alas, given your other restrictions, I suspect that it is your only option, though you could take some steps to reduce the error-prone aspect (e.g., script that synchronized the contents).
Long-term, Gradle for Android will be The One True Answer for all builds, Eclipse included. At that point, I expect your "Link Source" will break. However, at that time, you should be able to cut over to Gradle for your builds.
Gradle allows developers to override the default locations of all sorts of directories, including the assets directory. You should be able to set up a build.gradle file that points to some common location for the assets directory, overriding the default location that looks inside the project itself.
It's unclear why you think that symlinks/hardlinks will not work for you as a stopgap measure. You might wish to consider asking a separate StackOverflow question, explaining what you have tried and what problems you encountered with that technique, whether you think we will believe them or not.
Bear in mind that while Eclipse handles the javac step for the Android build, everything else is largely handled by external tools (e.g., aapt). Those will be oblivious to things that exist solely in Eclipse-land. Conversely, that's why symlinks/hardlinks should work, as from the standpoint of those tools, such items should be treated the same as actual files in the filesystem. Hence, the reason why "Link Source" works is not because Android really supports it, but that Android presently delegates that one piece of the build to Eclipse itself. Once Google adds Gradle for Android support for Eclipse (which I hope will be before the end of 2014), then I would expect Eclipse to be completely cut out of the build process, and I expect "Link Source" to fail at that point.

how can I access SVN from an Android device

I've been trying to use SVN Kit to gain access to an SVN repository from an Android app.
Our project is supposed to check for changes to files and download them if they have changed, but still with the ability to rollback to previous versions if nessecary.
I set up a regular Java project, and had no problem using SVN Kit, I logged into the SVN server and retrived a list of the files stored there.
But when I tryed to do this from an Android project all hell broke loose. The VM run out of heap space, just trying to build it and Eclipse went down in sreaming flames mith comments like 'GC overhead limit exceeded'.
I get the impression that this is due to the diffrent type of virtural machine that Android uses, and the SVNKit jars are compiled for a diffrent type of VM.
This Guy claims to have got it working, with what looks like an older version of Android.
Now I have suggested that we use some kind of ftp server approach, uploading new versions of the files, perhaps with seperate files containing versioning information, but I have to explore this path before I write it off as a dead end, or at least suggest that to my boss!
anyu help or suggestions would be greatly appricated.

My answer may not be directly related to SVNKit but would actually try to address the original problem.
As I understand your use-case, you want to download files if they have changed and are trying to use SVN to do this with its update command. I would rather create a simple web-service which should return me the list of files with their checksums or md5Hash. Now I am assuming that only the relevant files are present on the server. Upon receiving the hashes, you can compare them with the hashes on the device and decide to update based on any difference. This approach will work for rollback too as you need to just replace the file on the server with old file and this would be treated as a new one.
As far as heap overflow and out of memory is concerned, they are mostly because of the limited heap space around 10MB.

I created a SVN client based on SVNKit it is available for free here : https://play.google.com/store/apps/details?id=com.valleytg.oasvnlite.android
I am not sure if that will work for your purpose or you have to build your own. If you are looking to build your own, svnkit will not work directly on the android platform. Some of the libraries used by SVNkit are not available on the Android platform.

forensic tool for Android

I am doing a forensic course and as a requirement I have been asked to develop a forensic investigation tool (windows based) for Google's Android OS. The requirement is such that given an image file, the tool should be able to display the databases that the applications are using, call history, messages and etc..
I have little experience in Java but I have no experience in Android development. The research so far has given me nothing on how to go about this. If anyone could point me in the right direction I would much appreciate it.
Thanks in advance.

Step 1 would be mounting the filesystem. Since Android is Linux based, there's a huge array of filesystems available, and individual vendors may or may not decide to write their own filesystems, just for the fun of it. On Windows, your options include ext2fsd or ext2read, among other possibilities.
Once you've got the filesystem mounted, then you get to deal with the per-application data storage. I'd wager a fair amount of applications use SQLite3, because it is an amazing tool. But you'll have to figure out, for each type of data you want to read, where it is stored and in what format. (The standard file(1) tool on Linux systems can come in handy, it knows heuristics that are surprisingly good at showing what type of file you might be dealing with.)

If you have the .apk of an application, a tool such as dex2jar, used in combinaison with something like jd-gui, can get you the JAVA source-code of the application (which can help, if not obfuscated).
After that, an .apk is basically a zip-file -- which means opening it with an unzip-ing application will allow you to get the images and resources it uses.
Then, databases used by Android applications tend to be SQLite, on which you can do SQL queries, using an SQLite client.

Git for Peer to Peer content distribution network

Is there anyone using git in such a fashion?
I would like to distribute some multimedia content from a server to some Android remote devices. I would like them sending back a log file with device usage statistics (provided by an android app I will write).
The server could be anything but I would prefer a linux box.
I thought that since git handle and sych only differences between files, It would be a nice tool for this purpose and I would have content revision history as a bonus.
I need some piece of advice on how the repositories architecture could be organized: does It have to be a star topology or something different?
The remote end of the sistem don't need any interactivity, in other words the remote git repository could pull and push whatever It needs to, autonomously and automatically.
UPDATE: I've found here on SO the author of git internals (I'm downloading It right now), Scott Chacon talking about the architecture I would like to implement.
UPDATE 2: OK I read the chapter about "Non-SCM uses of Git" and here is what the author says about a Peer to Peer CDN:
You have to get new content [...]
consist of any combination of xml
files, images, animations, text and
sound. You need to build a content
distribution framework that will
easily and efficiently transfer all
the necessary content to the machines
on your network. You need to
constantly determine what content each
machine has and what it needs to have
and transfer the difference as
efficiently as possible.[...]
It turns out that Git is an
excellent solution to this problem.
I don't find anything about mentioning little portions of the book inside it, so I hope that I'm not violating any copyright. In any case I will delete It if someone complain.

I would suggest against using git for such purpases. For starters, Git will use extra phone storage for the revision history, and it will send entire files (not deltas) anyway because multimedia content is binary and diffing does not work on it. Just implement a method to list server-side multimedia with last-modification dates and another method to download updated files (I would suggest HTTP as it is the simplest). On the server side, you can of course use git internally for versioning the multimedia files, but I'd rather not expose the git interface.

The git protocol tries to send patches instead of whole files, but the git storage engine always stores whole files, and always keeps old versions of the files. git is probably not the tool for the job if you aren't trying to keep file history.
rsync is a mature file distribution system that can work over ssh or its own protocol (the same as git), can make binary patches, and doesn't necessarily keep change history. Probably start looking there to see if you can get that work.

So in a previous job, we used Git for exactly this and the reason was that our media assets were not often changing, so no matter what we used it was likely we would have to send the whole file anyways - thus, the issues with binary deltifying, though also an issue with other content distribution tools, was not important.
The main advantage to rsync (and presumably unison, though I've never used it) is that you can build the content trees in the index and store the trees in Git under a branch per client rather than having to have everything on disk to run rsync on. If you have several variations on content, it's pretty cool to be able to record unique trees of content needed by each client - of which you could have thousands of combinations - and have a simple pull command fetch only what's needed and update it on the client. That was the reason we choose Git instead of rsync to do that. If every client needs exactly the same set of data, perhaps rsync would be easier, however the other nice thing about Git is that you get a history of the content on each client - when and how it changed for every single client.
We also used it to record log files - since they are generally pretty uniform and text based, they delta excellently and transfer very efficiently - we were very happy with using that to record and transfer back upstream our log data.