I have an Android app that will be distributed in two (or more) brands. All java code for each distributions is exactly same, just different assets/resources (like layouts, drawables, dimensions, etc)
What is the best way to organize the project? I am using Git for version control, and trying to keep all distributions developed as a single project. So I can switch asset/resource sets easily for different branding each time needed.
Is there a good approach for it?
One good approach would be turning your main project code in a library and then, for the other projects (brands), import that library and override the assets as you want.
Gradle Build Variants allow you to have a shared main codebase/resources and multiple variants with custom resources/code associated with each - you then can generate a separate APK for each variant. Of course, using Gradle for Android development requires you use Android Studio (which is currently in beta) as well.
As mentioned above, Gradle Build Variants is the best way to handle this. We have 11 variants (and counting) where the only difference are some configuration values. I organized the project as follows:
app/src/configurations/
flavor1/
common/res/...
release/res/...
stage/res/...
where the common directory holds configurations common to that build variant and the release and stage hold custom values for our release and staging versions (they have slightly different configurations as well).
All configurations common to all build variants live in the normal app/src/main/res folder.
Then in the app's build.grade, I have each product flavor defined:
productFlavors {
flavor1 {
applicationId = "com.example.flavor1"
}
flavor1stage {
applicationId = "com.example.flavor1stage"
}
// etc. for each build flavor
}
android.sourceSets.flavor1 {
res {
srcDirs = ['src/configurations/flavor1/release/res', 'src/configurations/flavor1/common/res', 'src/res']
}
}
android.sourceSets.flavor1stage {
res {
srcDirs = ['src/configurations/flavor1/stage/res', 'src/configurations/flavor1/common/res', 'src/res']
}
}
Related
I have 3 jar files in my Android project's app/libs folder:
api-dev.jar
api-qa.jar
api-prod.jar
I want to use api-dev.jar when I work on the app in the studio (default), build a version of the app using api-qa.jar which will be tested by the QA team, then release the production app with api-prod.jar.
How should I do?
So far I read that I should add a
configurations {
qaCompile
...
}
element to app/build.gradle and use
android {
buildTypes {
...
qa {
...
}
}
}
to define the builds.
I don't know how to point to the appropriate libs/dependencies, I don't know how to make one the default one either, especially in my case where the default one is not the one for the production release...
Also if the API requires a specific key for dev, qa and prod, how do I set it up?
By the way the features are exactly the same between the different builds, the user experience is exactly the same, it's why I want to use builds, not flavors.
Check this out - Add dependency to specific productFlavor and buildType in gradle
Add you jars to the libs directory
Create a build type and product flavor
Use the name to create a specific compile command
Use that to specify your jar file in the libs directory
I have followed Google's official doc for creating multiple APKs for different API levels. (I know it is not recommended to have different APKs, however in my specific case I must use it).
The only difference between the two APKs in my case would only the AndroidManifest.xml files content. While reading through the official doc which recommends creating a shared library between two different apps modules, I wondered whether it is going to be possible to achieve the same through different flavors in Gradle's build setting, specifying a different AndroidManifest.xml file for each flavor and thus generating two APKs with different manifests (the idea came from this post).
Since creating two flavors is much simpler (time and maintenance wise), and my only need is two different manifests files, isn't this a better option than the suggest common library module shared between two different app modules?
You should check about Product flavors
A product flavor defines a customized version of the application build
by the project. A single project can have different flavors which
change the generated application.
Structure
android {
productFlavors {
dev {
applicationId "root.com.android.dev"
}
product {
applicationId "root.com.android"
}
}
}
You can read also
Product flavors in Android Studio for hermetic testing
We have a platform to read poetry with a SQLITE Database say SHAKESPEARE.DB .
We also have another poetry say Wordsworth.DB.
So for each poetry database we want to create a separate application like Shakespeare.apk and wordsworth.apk.
During build we want to mention the Database and mention the name of the APK.
How do we Change Database during android build through gradle and deploy different APK's
I would want to Create and Deploy Database specific APK using Gradle ?
Step #1: Use a consistent means of embedding the database in the app. For this answer, I will assume that you are using SQLiteAssetHelper, with the database packaged as words.db in assets/.
Step #2: Create two product flavors for your app in your app/ module's build.gradle file. For this answer, I will call these flavors vanilla and chocolate:
productFlavors {
vanilla {
applicationId "com.commonsware.android.gradle.hello.vanilla"
}
chocolate {
applicationId "com.commonsware.android.gradle.hello.chocolate"
}
}
(replace the applicationId values with ones more relevant to your project)
Step #3: Create a sourceset for each flavor (app/src/vanilla, app/src/chocolate/).
Step #4: Put a different words.db in assets/ of the flavor (app/src/vanilla/assets/words.db, app/src/chocolate/assets/words.db).
Now, when you build vanilla, it will use the vanilla edition of words.db. When you build chocolate, it will use the chocolate edition of words.db. No Java code changes are required. You can also put different resources in those flavor-specific sourcesets, for different icons, labels, etc. Because you have different applicationId values, both flavors can be installed on your test devices at the same time, and both flavors can be distributed through app distribution channels like the Play store.
I have two apps that shares same functionality except images,icons,colors,app name and package change and the URL that gets called in the event of network activity.
In iOS we can create two different apps easily from one source code by using the power of targets.
Here is the link on How to do it in iOS
But how to go about it in android
You should leverage product flavors for this.
In your build.gradle, you will define the flavors like so:
android {
productFlavors {
brand1 {
// ...
}
brand2 {
// ...
}
}
}
You can then create flavor specific resources. If you are creating an icon called ic_launcher.png for example, you would typically put it at a location such as main/res/drawable-xhdpi/ic_launcher.png. Instead, you could put the brand1 version at brand1/res/drawable-xhdpi/ic_launcher.png and the brand2 version at brand2/res/drawable-xhdpi/ic_launcher.png.
When you run gradlew build, it will build all variants. You can also build specific variants such by specifying the variant name like so: gradlew assembleBrand1Debug. In Android Studio you can select the variant you want to see using the "build variants" pane.
I'm trying to understand how i can generate multiple APK from one single project.
I'm using gradle and this is my project's three:
ambrogiocore is the core library module that implements all the common classes and resources.
ambrogioremote is the module that has the :ambrogiocore dependence.
It's work. Now i'm able to generate multiple APK. (just one at the moment)
One apk for each module.
The problem is that i need to manually sync all the AndroidManifest.xml for every future module that i'll include in my project.
Is this the correct way?
Can i automate this operation?
I took a look at productFlavor. Just I don't understand if this tool can help me.
What do you think about?
THANK YOU ALL!
**SOLUTION**
Finally! I found the same solution proposed by #Kai!
Flavor is the way!
This is the best approach for a lots of reasons:
Single-module project
You don't need to copy XML files
RoboGuice will work like a charm. (RoboGuice presents some BIG problem on library projects)
http://www.techotopia.com/index.php/An_Android_Studio_Gradle_Build_Variants_Example
If by "one single source core and multiple project that extends "ProductName", "PackageName" and "resources"" you mean to provide each flavor with unique "ProductName", "PackageName" and "resources", then yes it can be done.
To give each flavor its own unique package, set applicationId for each of your flavors like so:
android {
productFlavors {
flavor_1 {
applicationId = 'com.app.flavor_1'
}
flavor_2 {
applicationId = 'com.app.flavor_2'
}
}
}
To give each flavor its own app name and resources, simply put them in a flavor's own directory, Gralde will merge a flavor's resources with your base resources to create a complete one.
For more detail on how Gralde flavors work, please see Gradle Plugin User Guide
This is my final solution!
All the common files, manifest and base resources are under "src/main"
I moved my projects inside "src/projects"
declared two productFlavor (one per project) specifying applicationId and versionName
created two sourceSet (one per project) indicating the specific res folder.