Develop Reference

Creating multiple new project apks from one parent project ionic

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)

How to use buildTypes, productFlavors, and sourceSet to batch build apks for different android channels

I'm new to unity3d , and I have to use it to batch build different apks for multiple android channels. I have to change project's package name, app name, icon, and meta-data values defined in AndroidManifest.xml, which is really boring me. What's worse is that I have to depend on different sdks that makes the project so heavy.
I know that android studio now is using gradle which can use buildTypes, productFlavors and sourceSet, manifestPlaceHolder, applicationId and some other configures to build different apks for multiple android channel.
I also find some plugins in github like https://github.com/zasadnyy/unity-gradle-plugin, but it can't use buildTypes or productFlavors features.
I wonder if it is possible to use gradle to achieve my goal? Any suggestions?

Not exactly what you're searching for, but you can also script the Unity build process to achieve the same thing.
You can do custom build with a combination of build pipeline and executing scripts from the command line.

Unfortunately, Unity's gradle support is substandard (as of Unity 2017 and possibly beyond). I would recommend using the Build Player Pipeline in combination with your own Post Process Build code to selectively enable or disable features and configure the output. You can configure the specific build using Custom Scripting Directives that can be modified in the Build Settings -> Player Settings panel when building the application.

In iOS do we have something like Gradle Build Flavors on Android

In iOS do we have something like Gradle Build Flavors on Android.
Basically I want to integrate Applause SDK with my app but I dont want that code to be part of the release build. I only want to use applause sdk only to distribute the app internally and for bug reporting.
If there is nothing like flavors then what is the best way to do this.

You can make use of Schemes and Build configurations in Xcode. Here's the official documentation: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/Articles/BasingBuildConfigurationsonConfigurationFiles.html
After you create a build configuration, you should edit your scheme to use that build configuration. For that click on your scheme and select Edit Scheme.
In short, the process is:
Create a build configuration
Set some custom flags for that configuration. For this, go to your target, select Build Settings tab, and search for Preprocessor Macros. There you'll be able to add custom flags
Edit your scheme, or create a new scheme, to use your build configuration.
In your code, you'll have to ask if the flag is available using preprocessor macros:
#ifdef APP_STORE
//do something
#endif

There are several approaches you can take to build an iOS app in different flavors:
Different versions of a resource file
Use a custom build variable to switch between different versions of a resource file. This article discusses how to build an app with different icons.
For *.strings files and resources linked in *.storyboard files the suffixing approach suggested in the first item did not work for me. So I added a Run Script build phase early in the pipeline. Using a script you are free to do whatever you want before the usual build chain handles your files. This is great for dynamic file generation or advanced file selection logic. As a switch you can (again) use a custom build variable.
Modifiying code
Use a compiler flag as suggested here. These can be checked using the preprocessor.
Alternatively you can (again) check custom build variables. To make them accessible add them as a key in a plist file.

Android - testing vs. production version

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

How to have both Debug and Release apk on same device?

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