0

I have a small Android application that uses different sets of files (a couple of images, a small SQLite DB and a couple of XML files) depending on the specific task at hand.

I know I can include my files into the main application APK using resources or assets but I would be happy to distribute them in a separated APK.

How can I create a data-only APK file?

How can I distribute it? In particular, do I have to do anything special for a data-only package (for example for associating it to the main application package in some way)?

(I'm intentioned to give the user a link to the data package and ask him to install it. No automatic installation required.)

How can I install my files into the internal or into the external storage area of my application? Is it possible at all to install files into the internal storage area created by the main application installer? Do I have to set any particular permission for this?

AlexBottoni
  • 2,237
  • 20
  • 24
  • It looks like the suggested way to send data packages to an installed application would be Google Cloud Messaging for Android: http://developer.android.com/guide/google/gcm/index.html . This is still not what I'm looking for, unfortunately. – AlexBottoni Nov 29 '12 at 10:48

2 Answers2

1

My approach to this would be to create a wrapper app that's nothing but a content-provider and serves up the files per request by your main app. This would allow you to supply different data packages for the user -- you could even have your main app select between those relatively easily.

323go
  • 14,143
  • 6
  • 33
  • 41
1

It looks like that the commonly accepted way to have the same application with different contents (or styles, or configurations) is to use an Android Library Project for the common code (that is: the whole application, the "engine", the "app framework") and a standard Android Application Project for the contents (that is: an application that actually contains just data). A little bit confusing, just because the "library" here is actually the whole "app", but this seems to be the way to go.

More in detail:

  1. Create an Android Library Application and put into it as much code as you can (all of the non-changing stuff). Please note that this library cannot be launched and cannot be distributed alone. It must be included in a hosting application.
  2. Create a standard Android Application. Include your library into this project. Put in /res and in /asset all of your data (files, XML, etc.).
  3. Compile everything and distribute.

Repeat this cycle every time you need a different version. Different because of data, style, configuration or anything else. Publish the resulting app with a new name.

For what regards me, I'm not completely satisfied by this approach.

A possible alternative is preprocessing the source code with Ruby, Python, Perl, GIT, bash, Ant, Maven, Rake or any other tool that is able to read a file from here, make some change here and there, and write the file there.

The general outline is something like this:

  1. Make a "template" application. Leave your /res and /assset empty.
  2. Run a custom-made script. The script reads a configuration file, copy the /res and /asset files from your repository into the project /res and /asset directories, changes some Java source file and creates/changes some XML file.
  3. Compile and distribute (with a new name, of course).

Using GIT or other SCMs, you just make a new branch for every new version and compile it. Not very elegant (because it can strongly interfere with the normal use of the SCM) but...

There are a few example of these approaches on the web. I'm not completely satisfied by them, either.

Frankly, what the Android ecosystem should offer to solve this problem is some kind of "in-app package manager". Something like the Eclipse Update Manager. This would allow us to use the same application framework to handle different scenarios.

As an alternative, a solid, officially-supported, template-based code-generation mechanism would be nice. Something in the spirit of "Software Production Line": https://en.wikipedia.org/wiki/Software_production_line . Have a look at fw4spl, for example: http://code.google.com/p/fw4spl/ .

AlexBottoni
  • 2,237
  • 20
  • 24
  • I agree with your second approach, especially when the number of sub project becomes tremendous which make it hard to maintain (build, SCM tagging and etc). I had a similar discussion in [this question](http://stackoverflow.com/questions/10143352/eclipse-multiple-project-from-single-source/10240474#10240474) before which you probably interested. – yorkw Nov 29 '12 at 20:10