Develop Reference

Android - Same core features for multiple applications

I'm currently developing an Android app that needs to be distributed as separated apk to the store for n customers. All having same features, only the design differs or text sometimes.
How would you manage this? Which best practices would you recommend? I can definitely start from scratch again. It's a side project, so best practices first :)

You can use Flavors, For complete detail you can refer this Official doc.

Seems you need flavors. You can define for each flavor different versions of the files that vary either code or resources.
https://developer.android.com/studio/build/build-variants.html

Extension language for Android app

I'm writing a Android app for encrypting texts, and I wonder if I can use a extension language to write additional algorithms outside the app instead of writing them inside the app and recompile the source. After doing some researches, Lisp seems to be a good language to use, and I've come up with a few choices:
Write my own lisp. This seems to be viable, but I always have trouble with writing a new program, and debugging is very time-consuming. It won't be my first choice.
Use lisp written by others. I've been searching Java-lisp repos on Github, and I found some small projects that may be useful, but lack some important features I want to include. I can add more to others' projects and use, but because of the reason above, this is not a good choice either.
Use Clojure. This seems to be a good choice, because Clojure is a well maintained and supported language. The only problem left is how to integrate it into my app.
Number 3 is my preferred choice now, but I want to ask you to help me choose. Other solutions are also welcome. Thanks!

Android app accessing library resources

The project I'm working on requires that N stand-alone applications can be built but also an extra big application with a selection menu that will execute one of those.
The difference between these applications is mainly resources and XML, so they all use a common library which reacts to assets and the information provided in the XML.
The problem is regarding the "mother" application. It has to be able to use the common library using one of the stand-alone resources set. I realized I can access another application resources using:
Resources R2 = getPackageManager().getResourcesForApplication("com.example.appa");
int id = R2.getIdentifier("image", "drawable", "com.example.appa");
Drawable myDrawable = R2.getDrawable(id);
And this actually solves the issue, I can supply a package string to the library so it will know where to look for the resources.
Problem is, in order for this to work, I need to have those stand-alone applications installed on the device, and that's something I cannot do (think of it as a quiz application, the stand-alone apps are only one topic while the "mother" app allows access to all different topics and, as far as I'm aware, Android Market won't allow downloading all apps and installing them just so I can access their resources).
Conceptually speaking, this issue would be solved if I could make those stand-alone applications as libraries and adding them to the mother app. The mother app would then use a package string depending on user choice and then use the library. So far I haven't been able to work this out and I can't find information about this so I'm afraid this can't be done.
Each topic application has, for example, an intro.png with an image regarding the topic of the app (for example a roman or a greek image) and the idea is to access package_string.intro.png so it will automatically access the right one depending on user choice.

After struggling to do this I finally found out resources are indexed which means only one "intro.png" exists in one application, no matter how many libraries you try to link, you can't create a reference to lib1.intro.png or lib2.intro.png. I finally built a resource manager system which works with "lib1_intro" or "lib2_intro" on demand. Not the cleanest of solutions but, meh, it works I guess...
Moving my edit to an answer as I read about accepting answers and this is how it should have been done instead of just editing my first post

Detect locales available on device

I am implementing overriding the locale of the device in my application allowing the selection of a different language via a preference.
Now when presenting the list of available languages I am looking at using Locale.getAvailableLocales() to see which ones are installed on the device.
Will that work and e.g. only return a smaller set of locales if they are not fulled installed down to the needed fonts and so on?

As Android's Documentation states:
Most locale-sensitive classes offer their own getAvailableLocales method, which should be preferred over this general purpose method.
To me that means you should test against these methods to be on the safe side. So it seems that the answer is no. However, in terms of installed fonts, I believe that system provides a way to display almost any language. Some symbolic glyphs might be missing but I don't think it regards to regular characters (or maybe it does in regards to some obscure scripts but I don't think you would use them).

How do you release two versions of an app on the Market?

I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.

This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/

People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.