I am facing problem. I need to build one app in two ways, first build is for development (testing) use, second build should be production version. Are there any ways how to do it programatically? (with some build engines) I mean that both apps shloud run on one device at the same time if possible. Both version are APK from one Android project.
Thanks
Personally I use this to determine whether I am in debugging mode:
final PackageInfo pinfo = getPackageInfo(ctx);
final boolean debugMode = (pinfo.applicationInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
This code is based on the debuggable attribute of the Application tag of the android-manifest.xml:
If this attribute is explicitely set to true debugMode will be set to true.
But if it is explicitely set to false or not present in the xml (implicit values), debugMode will be set to false.
Doing this way you cannot run both app on the same device at the same time as two APK need two different package name to be installed concurrently. So you have to build two eclipse projects, each one having its own package name (for example com.example.myapp.debug and com.example.myapp), and why not using a common lib (com.example.myapp.common) that would contain almost all your code:
com.example.myapp.debug has its debuggable flag set to true
and com.example.myapp has its debuggable flag set to false
As far as I see, you really need to create different applications from you base code. One way to get this done, as I did it, is to use Ant script that copies the entire project source into another directory, say "testing", and while doing so, replaces (e.g. using copy filtering) certain values from XML files, like from AndroidManifest.xml. One of the first things to replace is applications package that needs to be unique for each app. The Java classes like Activities can still reside in the original packages, their names in AndroidManifest.xml just need to be absolute. Once source has been copied and filtered, you can use Ant's antcall task from the main build.xml to build the customized app. So at the end, you can say e.g.: "ant -Denv=testing build" and you have an APK that can be installed next to your production version.
Another alternative is to use Maven that's Android plugins support project overlaying. And of course you can use library projects, see: Android – multiple custom versions of the same app.
I think that the easiest solution is to use some kind of source control tool for this purpose. There are so many good reasons to use source control, that I believe that most developers already use it.
Summery of solution:
Have 2 repositories (or branches), one for development and one for production.
Choose different package name for production and development apps.
Use absolute path for activities rather than relative in manifest file.
Solve the conflict only in the first time that you pull the changes from the development to the production environment.
Description of solution.
I personally works with GIT, I believe that this approach will work with other SCM tools, but I didn't test it.
I have 2 repositories, one for development and one for production (You can get the same effect using production branch, but I preferred different repositories, since I never know when I'll have another developers, and I don't want to give anyone (including me) the chance to do a mistake with the code without having a backup for it.
All you need to do is to set different package name in the manifest file in each repository, for example:
Development manifest package name - dev.com.foo.appName
Production manifest package name - com.foo.appName
For each activity there is a need to use the absolute path rather than the relative approach. Since there is no real option that you will change your package name, and if you do, all the changes are in the manifest file, I don't think that there is almost any drawbacks with this approach.
Then every time that you pull your changes from the developer repository to the production one, there should be a "conflict" on those lines in the manifest files, but actually there will be a conflict only on the first time you pull the code, afterwards the merging tools knows which line you prefer in the production repository.
EDIT
After using this approach for some time I discovered that there is a problem with the generated R file.
The problem:
R file is being generated with package name as defined in the Manifest file in the package attribute. Then all references to R file cannot be find (The package name of the source files is differed from the package name stated in the manifest file).
There are 3 solutions for that problem:
The Good:
This solution is the most robust one, and I suggest you to use it (didn't try it myself though). The idea behind this solution is to generate the R file into a different class name than the one stated in the manifest. In the manifest the package would be dev.com.foo.appName but the R file will be generated to the com.foo.appName.
In order to achieve it please follow this answer
The Bad:
Do NOT use this solution, it is really bad, I'm stating it here that you could avoid it. In each file that using the R file add the import to the R file with the package name is in the manifest. This is a very bad solution, since you will enter a lot of unrelated code, you will need to change it in the production environment, and for every new class you will need to remember to add it.
And the Ugly:
It is better not to use this solution since it is a kind of a hack. This solution is useful only for mature apps that don't have lots of changes in their resources. When ever you change your resources the R file is being generated again, then it is generated to the package name as in the manifest. All you need to do is to change the package name (in the manifest) to be as in the production environment, clean the project, build it again, and change back the package name into the development environment. Then eclipse asks if to change configuration and you choose not to. This way, 2 R files will be exist, one with the development package name and one with the production one. Since in mature apps there are not much resources changes, you will be doing so once in a while. You won't be able to forget about it, since in case that you change a resource you will start seeing weird bugs.
I know question is late, but I will answer.
You may use Gradle.
In build.gradle file you may define separate buildTypes like this:
buildTypes {
release {
runProguard false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
test {
applicationIdSuffix ".test"
versionNameSuffix "t"
debuggable false
}
By set applicationIdSuffix for may install test and release build on one device
For more info go to http://tools.android.com/tech-docs/new-build-system/user-guide
Related
This question may seems old to some you guys or may be silly or may interesting , but i really want to know this.I build an application in ionic but now as i want to make such automated system like i can make multiple application's apks from the existing parent code with different package names and version codes.I want to make such a script that when i run it on command line i will be able to build a new apk from the parent code just by changing logo and package name , version code , version name.As the functionality will remain same only base url , package name , version code need to get changed . so i want this process to reduce my efforts in generating new apks manually.
I done some R&D and found some links but i am not able to understand them clearly , as i never use ant or maven earlier , After seing such links i believe that this can be possible . So , i just want to get sure of this and want to take idea from all the experts here in stackoverflow.I really want to learn this amazing thing.
links are as follows :-
Create an Android project from existing one
How to compile APK from command line?
http://www.simpligility.com/2010/11/release-version-management-for-your-android-application/
Found This But it is Unanswered :-
Generate multiple APK's with same code base using ANT
I found this But i do not know how ruby works and how to use this in ionic framework:-
http://iambrucewang.blogspot.in/2012/03/create-multiple-android-apps-from-one.html
I am using Linux mint and eclipse as IDE .
Please enlighten me with your expertise knowledge.I will be very grateful to you all.
Regards
First of all: Don't use Ecplise anymore as an Android IDE. The Eclipse Support for Android is outdated and Android Studio will bring you joy.
Regarding your question: You are asking about build types (i.e. develop, release, ...) and build flavors (paid, free, whatever, ...).
You can define these two in the gradle file (don't use Ant anymore. For Android it's as outdated as Ecplise). For example you define two flavors: logoOne and logoTwo. For each flavor you can either use different implementations for classes who need to do different things OR you can also define BuildConfig Fields with more or less hardcoded information.
More about this here:
https://developer.android.com/studio/build/build-variants.html
or on youtube here:
https://www.youtube.com/watch?v=cD7NPxuuXYY
This will generate seperate APKs for each build variant (= combination of buildtype and buildflavor)
is there a simple way to have installed two version of the app on the same android Phone?
Im updating a old web app to a native android app. For testing purpose it would be great if we could have both installed at the same time on the same device.
It would be great to rename the update just temporary.
If I rename the package name in the AndroidManifest, then also R will be renamed and I have to reorganize the imports etc.
Is it possible to do a simple rename only somewhere in the AndroidManifest without changing a single line of code (even not with eclipse / android studio refactoring mechanism).
I have tried to mark my native app as library project and to include it in a new Android Project with another package name. But I will get trouble with this approach, for instance with actionbar sherlock:
Unable to execute dex: Multiple dex files define Lcom/actionbarsherlock/R$attr;
Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/actionbarsherlock/R$attr;
If you are using new gradle build system you could create new build type and then just add packageNameSuffixto it. This will add suffix to your package name but everything else stays the same.
buildTypes {
debug {
packageNameSuffix ".debug"
}
}
There is an easy way if you want to do it temporarily. You need to modify the AndroidManifest.xml file.
Find the line that looks like this:
manifest package="com.example.myapp"
and change it to something like:
"com.example.myapp.debug"
AFAIK there is no way other than changing the application package name, but it's fairly easy.
In Eclipse, right-click your project and select Android Tools > Rename Application Package.
I have several options - both in code and in the manifest file - that I would like to easily toggle on and off based on whether it's a debug build or release build.
What's the best way to handle things like this in an Android application?
You could use properties files, e.g. one for prod and one for dev. Then you could create an Ant script with two targets, a prod build and a dev build, where the appropriate properties file is copied prior to the APK being built. Make sure that the properties files are copied using the same name, then you can access the deployed one, irrespective of the environment you built for.
In addition to what Tyler mentioned, if you are looking at including optional code in case it is a Debug and not having that code if its a release, then you could look at using the BuildConfig file that is generated by the ADT.
As per the docs: " Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfig containing a DEBUG constant that is automatically set according to your build type. You can check the (BuildConfig.DEBUG) constant in your code to run debug-only functions such as outputting debug logs."
You will find this file in the Project/gen folder, the same place where the R.java is generated.
Now with Android Studio and Gradle it is easy to do this using the auto generated flag BuildConfig.DEBUG. Like:
if (BuildConfig.DEBUG) {
// Debug code
} else {
// Resease code
}
I have an Android project that I recently published to the market after running it through obfuscation with ProGuard.
The project exported without any complications, but how do I know it's been obfuscated? Is there anything I could do to verify that obfuscation was successful?
Look for dump.txt, mapping.txt, seeds.txt and usage.txt. They will probably be in a proguard folder at your project directory. These are created when ProGuard is run on your code.
These are filled with information about the obfuscation, especially useful is mapping.txt which shows what ProGuard turned your various member names in to.
Try to reverse engineer your own application. See what you can read in the code.
Use the following questions:
decompiling DEX into Java sourcecode
http://www.taranfx.com/decompile-reverse-engineer-android-apk
DISCALIMER: I am not the owner of decompileandroid.com and I am not paid to promote it. I am a develper, who is satisfied with this service.
There is actually an easier way than acquiring several different tools and passing the output of one of them to the other (this of course gives you a better control of what's going on). You can use the service
decompileandroid.com
Basically you upload and .apk file and it does all of these steps for you.
Then you can download a .zip file, which contains the decompiled sources.
You can first upload your .apk built in debug mode, then upload an .apk built in release mode. Just make sure that the flag minifyEnabled is set to true in your build.gradle file for the release build.
The difference was pretty obvious in my case - most of my classes were named a,b,c, etc in the minified build.
While continuing to develop my application and test it on a real phone, I need to have the release version of it on the same phone, for demonstration purposes (the release version is much more responsive, thanks to no-logs).
The problem is that the only way to make two applications co-exist on the same device in Android is by having different package names.
But package names require re-factoring and lots of propagating manual fixes... not to mention that this confuses version control...
Ideally, Eclipse+ADT would allow appending a modifier variable that would automatically generate a different package name for debug/release and would allow such co-existence, but I couldn't find any mechanism that allows doing that.
Do you know of any way to workaround this?
Creative solutions and ideas are welcome.
Use Android Studio because gradle make your life a lot easier - just use applicationIdSuffix
android {
...
buildTypes {
release {...}
debug {
applicationIdSuffix '.debug'
}
}
}
For more go here.
The only way I know is to change the package name in your applications manifest file. Eclipse should handle all the code renaming for you.
Could you put all your code in a Library Project and then just have two normal projects,
that have different package names and just include the library project in both?
This should keep all your code in one place.
The normal projects would most likely only need a valid manifest file that points to the
activities in the library project.
You may want to try this technique using ant, Jenkins and perhaps other tools to automate package renames as suggested by #LAS_VEGAS.
Although not what you asked for, this cool code snippet can help you find out at runtime whether your code is debug or release.
Another interesting such attempt can be found in this thread. I am not sure though if it works on Android.
In Android Studio, Adding build variants using Product Flavours which can be easily customized for various environments and to test side by side multiple app variants of same app. Check out this link for more information - Configuring Gradle