I have an app that, for release, needs building as two apps. The app will self-reconfigure based on the app's namespace, so I just need to build two versions, each with its own slightly different namespace.
I obviously want to avoid changing source code package names, and would like to change the name space in one place so building either version is quick and easy.
Can I simply change the package name in the <manifest> tag in the Android manifest, making sure my references are fully qualified? Are there any gotchas with doing this?
Have two separate application projects, with separate package names, and have the common functionality - the bulk of your code - in a shared library project.
Related
I'm building an app from github source, and I need two different versions of it on the same device.
What's the minimum an app must differ, to be a different app?
I'd like a small change, and not rename packages everywhere.
NB: No gradle. I'm doing it on the device itself (using termux), which lacks gradle.
The app itself has some native code, and a few different packages.
It seems the package name in the AndroidManifest.xml must differ, and of course any classes referenced explicitly referenced in the AndroidManifest.xml must also exist.
But is that enough? Specifically, can the following be the same:
everything else in AndroidManifest.xml?
all other classes in the main package?
other packages in the app?
native libraries?
I'm guessing that all the other names in the manifest are just decoration, and don't identify the app. So that e.g. different apps could have the same name on the homescreen.
The package name is used to name the directory the app is installed in, so all its other data - dex classes, native libraries etc - are distinct.
It would be sensible for android to load each app with a different classloader, so different apps can have the same packages. This avoids clashes in the common scenario of different apps using the same (popular) library, that uses static/class fields.
My guesses are derived from this answer:
https://android.stackexchange.com/a/20793/108921
If so... I could just make one new package, move the classes referenced into it, and use this new package name in the AndroidManifest.xml. (There might be issues with these classes accessing other classes which were formerly in the same one package, but I suppose that's a different issue).
its hard to believe... package name is like ID i think... google play store also use package name as ID... every app has to unique ID in every device, and finally i can say its impossible you can install 2 app have same package name in 1 device
You just need to change the package attribute in the AndroidManifest.xml (manifest package). This can differ from the java packages of your codebase.
There's some caveats. The aapt tool uses the manifest package to generate R.java. Any relative names (of Activities etc) in the AndroidManifest.xml are completed into absolute names using the manifest package. To avoid this, just use absolute names.
As a convenience, the --rename-manifest-package option of the aapt tool does that. i.e. completes any relative names, then changes the manifest package to the argument given.
I've tested this with a simple project, and confirmed it works to install different versions of the same app on the same device.
I haven't tested more complex projects... There may be further caveats, with aspects of the AndroidManifest.xml that constitute a public API, and Activities, Services, ContentProviders and BroadcastReceivers that are referenced with explicit Intents. Things That Cannot Change
20 June 2011
The docs confirm you can change your java packages from the original; and that you can create different versions (flavors) of the same app. Unfortunately, it's discussed in terms of an extra layer of how gradle reads and updates the AndroidManifest.xml, not doing it yourself directly:
Set the application ID
I have an android application for one client, and he wants to make a 99% similar app for different country.
Almost everything is the same, only a few bitmaps would need to be replaced, address of API server will change, language file will change, but the code should stay the same, BUT I will need a different package name.
What is a simple way to make a clone of the app that will allow me to make code changes to one version, merge them with the new version (or versions), but keep the package name?
Or should I have everything in one project folder and then write and run some script that will change package names and swap content files? My iOS friend will probably need a few different #defines, but what should I do here, so I can maintain both versions in the future?
declare your original project as library, then create 2 new projects each for one language and let them include original project as library
then you can go ahead and just override bitmaps and constants you need.
this way, if you need any changes in core functionality, you just change your library project, and changes will propagate to both of extending projects
read more about library projects here:
https://developer.android.com/tools/projects/index.html#LibraryProjects
Since it's popular to have both a free and a paid version in the android market of the same app, I had decided to do the same. Initially I just duplicated the complete codebase and adapted some code here and there (added ads, built in some limitations etc) since there was no option to do library projects at that time, but that left me with two projects that are horrific to manage fixes to bugs as I need to do those twice.
Since r14 we can use library projects with resources, so that would be a great solution to this particular problem as far as I can tell. Therefore I've read up on library projects and conciderations, and I'm curious to know what the minimum amount of files needed in the projects of the different versions are. My questions therefore are;
Could I have all of the code in the shared project, and have bare bone project with basically just a manifest?
If so, should I? is this the optimal way conceptually? (so apart from the fact that it depends on my code base)
How should I deal with library package naming, are there specific rules?
Are there tools about that can compare code from two different projects and perhaps merge them auto-magically or auto-manually, and which one is preferred?
If I understand your problem correctly, you want to create multiple Android apps that are similar to one another (i.e., have a lot of the same source code), but which are different in particular (minor) ways, and you want each of these apps to have a distinct package, so that it can be separately uploaded and distributed on an app store such as Google Play. A Project Library is an excellent facility for accomplishing those goals.
I'm assuming that the differences between your various versions are minor, involving things like resources and the app name and package, and a switch that turns on certain features for a paid version while leaving them off for a free version.
Even if that is not the case, by using polymorphism in the ways described below, your various apps could differ in significant ways and still share a common Project Library.
A Project Library can be defined in Eclipse in the same way as any Android project can be defined, but it is marked as a Project Library (by checking the "Is Library" box near the bottom of the Android page of the library's Project Properties dialog) and cannot be compiled and run on its own. Instead, it is intended to be included by reference in one or more other projects which are actual apps (by adding a reference to it on the Android page of each such app's Project Properties dialog). These apps will use the Project Library, and thus will share its code and capabilities.
Each such referencing app will have its own manifest file (where their respective, different packages can be declared), and they can also define their own classes (including classes derived from the Activity and/or Application classes of the Project Library), so that these classes can be specialized polymorphically for each app that uses the Project Library (e.g., by overriding methods or by providing definitions for methods that are defined as abstract within the Project Library's Activity- or Application-derived classes), although you can also use those Library classes without modification (provided that they are not abstract) by simply referencing them within the manifest file (e.g., in an activity or application tag) of each app that uses the Library, just as you would reference Activity or Application-derived classes defined within the app itself.
If you decided to use this approach, then you would put your main source files in a Project Library, and would create a separate project for each app you want to produce, each of which would reference the Project Library. The manifest file of the Project Library would be overridden by the manifest of whatever project is being created using that Library (actually, I think that the Project Library's own manifest is completely ignored, not just overridden, but nonetheless it is useful to create a manifest for the Library, so that you can manually template - copy and edit - the manifest of each project that uses it from the Library's own manifest).
I have used this approach to create multiple android apps that share some of the same capabilities, and it has worked very well for me.
Regarding package naming, any old package name will work for a library project, but of course it makes sense to use the same prefix for the Library Project's package as you use for your various individual (e.g., free vs. paid) apps that use it, with something like ".library" as the last part of the name, while the various apps could have endings like ".myappfree" and ".myapppaid". Naturally, you would want to use your reverse domain name convention for the library's package prefix to prevent conflicts, just as you would for a package name of a released app.
In Windows, a nice, open-source tool for comparing code bases is WinMerge:
http://winmerge.org/
If I were in your position, however, I would only use this tool to manually identify differences, and would not attempt to use it to automate the refactoring of your code into a Library Project. That would be best done under your own (manual) control.
Finally, as an alternative, you might consider using a single app that is free and that has your free app's capabilities by default, with an option to upgrade to your full app's capabilities (delivered within the same APK) via an in-app payment, rather than having separate free and paid apps. In-app payments have improved a great deal in the past several months (with the release of version 3 of IAB), and although there are still some glitches, they have become a more practical alternative to the free/full dichotomy than they were at first.
Yes, you can have a project that is basically just a manifest specifying app name, name space, icon etc, with all the actual code and 99% of the resources in the library project.
Yes, I think you should use this approach. It's very common to use library projects to deal with the Free/Paid app problem.
I've not had any problems with naming, though you should be careful with any resources in separate projects to avoid using the same names.
I'm not aware of any tools, and if it were me I'd want to do it manually to be sure I'm merging what needs merging and keeping separate what needs to be separate. you've one significant refactor to do, but once all the duplication is removed I'm sure it'll be much easier.
I have a small Android project that I use as a core project. From this core project I want to be able to do customisations.
So I have the app in a framework format using standard icons, buttons etc... I want to be able to create different versions with different icons and buttons.
This I know how to do. (I will have two separate apk files, both with the same code but with different resources)
However I want to be able to install the core project and a customisation on the same device at the same time. Currently one will overwrite the other.
I have tried to change the package in the manifest but this in turn means I would have to also change all the imports for R.java in my Java files, this is something I want to avoid.
Is it possible to change just something in xml that will allow me to have two projects using the same Java files but with different resources?
You should use Android Libraries.
Put all your application code into one Android Library and then create two Android Applications which have custom icons and different package names. The resources defined in final Android Applications will override all already existing resources in Android Library.
One drawback: you'll need to have to almost identical copies of AndroidManifest.xml files in your Android Application (but they still should have different package names).
For more info:
Android's documentation: Settings up Android Library project
My post: Android Application, Android Libraries and Jar Libraries. This one describes how Android Libraries work.
You should create a library project that contains all of your source code, and create a project for each of your installable packages that references the library project. You can then define/override any resource definitions in the installable projects
I am including a class in my app that another developer has made freely available. His class has a different package.
Will this cause any issues on Android, the market, etc? Does every single class in the app need to be my own package?
Despite this being a very old question, I'd like to clarify: Java-level "packages" (which the question is about) and Android .APK "packages" are two different beasts. Java-level "packages" are namespaces to organize classes within your app, whereas the Android "package" name provides a globally unique identifier for your entire app.
Usually at least part of the Java sources in a project is in a Java-level "package" (namespace) matching the Android package name of the app, but that is just for convenience and is not at all required. It is very common to have several Java packages within your app project. Adding to the project 3-rd party Java classes with different namespaces does not affect the name of the resulting Android package. The entire project must have a globally unique Android package name defined in the Manifest, which is later used to identify your app within Google Play.
You are allowed to use other packages, sources and libraries. Eclipse makes that all very easy to do in the properties page of the project.
The main issue is usually making sure you obey the licences and agreements of the code you are using. Make sure you understand the implications and include credit to the developers, as well as references to the agreements as they state. If you don't, it could cause problems down the line.
It doesn't have to by in Your own package. Also You can use external jars, or external eclipse projects or external source folders for easier project maintenance.