Android Flavor ACTION_CHANGE_LIVE_WALLPAPER - android

Hi I'm trying to implement android app flavor (free and full) to live wallpaper. In eclipse, I used to use this following code to open live wallpaper preview from my own android Activity:
Intent intent = new Intent();
intent.setAction(WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER);
String pkg = WallpaperService.class.getPackage()
.getName();
String cls = WallpaperService.class.getCanonicalName();
intent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
new ComponentName(pkg, cls));
But now it does not work correctly as the free and full flavor are using same package name with just different applicationId in android studio. The problem is when it starts either in free or full version, it will goto full version no matter how, regardless of what flavor it is. I specify app flavor using applicationId in project gradle like this:
productFlavors {
free {
applicationId "com.kkl.app.free"
}
full {
applicationId "com.kkl.app"
}
}
How do we make it to get the correct package name that matches the app flavor?

You can call getPackageName() in your Activity to get Android packageName. This will be packageName from manifest file i.e. the one equal to current applicationId.
Method documentation can be found here.

Fixed by using the following:
intent.setAction(WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER);
String pkg = getPackageName();
String cls = WallpaperService.class.getCanonicalName();
intent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
new ComponentName(pkg, cls));
Special thank to Lingviston

You can do a lot with flavors, but what you are trying to do is far simpler than anyone has answered.
First you have a build variant to select your flavor for debugging and running. So use this, otherwise all your debugging will use default main release.
Secondly, you don't have to get package name, just use a build config flag or check flavor. I.E.
android {
signingConfigs {
releaseA35Demo {
storeFile file("$projectDir/../yaskeystore.jks")
storePassword System.getenv('YOUR_APP_STUDIO_STORE_PASSWORD')
keyAlias System.getenv('YOUR_APP_STUDIO_KEY_ALIAS')
keyPassword System.getenv('YOUR_APP_STUDIO_KEY_PASSWORD')
}
}
flavorDimensions 'default'
productFlavors {
a35Demo {
dimension 'default'
applicationId "com.appstudio35.yourappstudio"
buildConfigField "String", "SERVER_URL", '"http://fakeNumbers.compute-1.amazonaws.com:3006"'
buildConfigField "int", "BUSINESS_ID", "1"
versionCode 1
versionName "0.01.01-b1"
minSdkVersion 21
}
a35DemoDev {
dimension 'default'
applicationId "com.appstudio35.yourappstudio.dev"
buildConfigField "String", "SERVER_URL", '"http://fakeNumbers2.compute-1.amazonaws.com:3006"'
buildConfigField "int", "BUSINESS_ID", "2"
versionCode 1
versionName "0.01.01-b1"
minSdkVersion 21
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
productFlavors.a35Demo.signingConfig signingConfigs.releaseA35Demo
productFlavors.a35DemoDev.signingConfig signingConfigs.releaseA35Demo
}
}
}
Then simply reference it in code like:
BuildConfig.BUSINESS_ID
Wherever you need it. Just make sure you don't accidentally use the BuildConfig of a library project when it auto imports the BuildConfig.
Next way is if you want to check your flavor you can simply do
BuildConfig.FLAVOR to see which one you are on. However, keep in mind there are some compiler warnings about using it because you are checking against a flavor and the BuildConfig assumes it will ALWAYS be whatever you are currently in for the Build Variant dropdown, Which is not true, you can ignore this always true or always false warning, I assure you it works.
Lastly your package issue is just because you are debugging the wrong build variant. I'll add an image so you can see where to change that.
Hope that helps.

Related

How do you install the dev version and release version of your android app? [duplicate]

Is it possible to change the package name of an Android application using Gradle?
I need to compile two copies of the same app, having a unique package name (so I can publish to the market twice).
As a simpler alternative to using product flavours as in Ethan's answer, you can also customise build types.
How to choose between the approaches:
If you need different package names to be able to have both debug and release apks installed on a device, then use the build type approach below, as Gradle plugin docs agree. In this case flavours are an overkill. (I think all projects should by default do this, as it will make life easier especially after you've published to the store and are developing new features.)
There are valid uses for product flavours, the typical example being an app with free and paid versions. In such case, check Ethan's answer and read the documentation too: Configuring Gradle Builds and Gradle Plugin User Guide.
(You can also combine the two approaches, which results in every build variant having distinct package name.)
Build type configuration
For debug build type, and all other non-release types, define applicationIdSuffix which will be added to the default package name.
(Prior to Android Gradle plugin version 0.11 this setting was known as packageNameSuffix.)
android {
buildTypes {
debug {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
}
beta {
applicationIdSuffix '.beta'
versionNameSuffix '-BETA'
// NB: If you want to use the default debug key for a (non-debug)
// build type, you need to specify it:
signingConfig signingConfigs.debug
}
release {
// signingConfig signingConfigs.release
// runProguard true
// ...
}
}
}
Above, debug and release are default build types whose some aspects are configured, while beta is a completely custom build type. To build the different types, use assembleDebug, assembleBeta, etc, as usual.
Similarly, you can use versionNameSuffix to override the default version name from AndroidManifest (which I find very useful!). E.g. "0.8" → "0.8-BETA", as configured above.
Resources:
This example is straight from Xavier Ducrohet's "Google I/O 2013: The New Android SDK Build System" presentation.
Build Types in the User Guide.
Myself I've been using productFlavors so far for this exact purpose, but it seems build type customisation may be closer to my needs, plus it keeps the build config simpler.
Update (2016): I've since used this approach in all my projects, and I think it definitely is the way to go. I also got it included in Android Best Practices guide by Futurice.
You could so something like this
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor1", "flavor2"
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
You can also change the field android.defaultConfig.applicationId if you want to do one-off builds.
Taken from: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration
With the gradle plugin version of 1.0.0+ you have to use applicationId as stated in the migration guide
Renamed Properties in ProductFlavors
packageName => applicationId
Thus in your build.gradle you would now use:
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
}
flavor2 {
applicationId "com.example.flavor2"
}
}
From Ethan's answer, both flavorGroups and packageName both are not available anymore. Below works as of March 2015.
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor"
productFlavors {
flavor1 {
flavorDimension "flavor"
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
flavorDimension "flavor"
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
I did not want to use Flavors, so I found a way to do so with buildTypes. I did this by changing my app/build.gradle file as follows:
defaultConfig {
applicationId "com" // See buildTypes.type.applicationIdSuffix
...
}
...
buildTypes {
debug {
applicationIdSuffix ".domain.name.debug"
...
}
releaseStaging {
applicationIdSuffix ".compagny.staging"
...
}
release {
applicationIdSuffix ".domain.name"
...
}
}
This allows me to have 3 apps next to each other on my devices.
I hope this helps others.

How to Run Different Product Flavors in Android Studio

I'm writing my first android app, and I'm just getting started with product flavors. I have an ad-supported app in beta, and I'm writing a paid version with no ads. I can compile both flavors, I think. When I open the gradle window, I see targets like "compile AdsDebugSources" and "compile PremiumDebugSources."
Now, if I double-click on either of those, the build runs to completion without error, but I can't figure out how to run the results. If I click on the green "Run" arrow at the top of the screen, I can never run the premium app.
There's only one entry, "app" that results in a an apk being installed and run on the attached device, and it's the AdsDebug version. I guess I need to add a new configuration, but I can't find any documentation that even mentions the word "flavor."
I've tried adding a configuration, but I don't understand what the questions mean. I looked at the settings for the default app, but they don't seem to mean much. How do I tell it that I want the premium version of my app?
Or does my problem have nothing to do with configurations? I've noticed that when I look at the Build/Edit Flavors the two flavors are listed, but none of the data fields are filled in. I would have thought that these would be copied from the manifest. Have I neglected something?
All I did to set up the flavors was to add this code to the app level build.gradle file:
flavorDimensions "dummy"
productFlavors {
ads {
dimension "dummy"
applicationId 'com.example.myApp.ads'
}
premium {
dimension "dummy"
applicationId 'com.example.myApp.premium'
}
}
What else do I need to do?
Open the Build Variants tool in Android Studio. By default, this is docked on the left.
It will show a list of modules in your project, with a drop-down for each indicating the build variant that will be used by the Run button.
SOLUTION
If you want to create different type product flavours (like different urls: development url, Quality url and production url of our application)
so you want to follow this code is working properly.
android {
compileSdkVersion 30
buildToolsVersion "30.0.2"
defaultConfig {
applicationId "com.premsinghdaksha"
minSdkVersion 17
targetSdkVersion 30
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
flavorDimensions "client"
productFlavors {
// use for production debug and release build
production {
dimension "client"
buildConfigField("String", "BASE_URL", "YourURL")
//if you want to use string anywhere of app show you define
// buildConfigField and get value where you want to use.
buildConfigField("String", "Shop_", "\"Shop1\"")
// production app name
//if you want change application name and app icon so you define
// resValue, manifestPlaceholders and get these value in Manifests file.
resValue "string", "app_name", "Your production name"
//production app icon
manifestPlaceholders = [
appIcon : "#mipmap/app_icon",
appIconRound: "#mipmap/app_icon_round"
]
signingConfig signingConfigs.release
}
// use for quality debug and release build
quality {
dimension "client"
buildConfigField("String", "BASE_URL", "YourQualityurl")
buildConfigField("String", "Shop_", "\"Shop2\"")
//use for quality app name
resValue "string", "app_name", "quality App name"
// use for quality app icon
manifestPlaceholders = [
appIcon : "#mipmap/quality_app_icon",
appIconRound: "#mipmap/quality_app_icon_round",
]
}
// use for development debug and release build
development {
dimension "client"
buildConfigField("String", "BASE_URL", "development url")
buildConfigField("String", "Shop_", "\"Shop3\"")
//use for dev app name
resValue "string", "app_name", "developer app name"
//use for dev app icon
manifestPlaceholders = [
appIcon : "#mipmap/developer_icon",
appIconRound: "#mipmap/developer_icon_round"
]
}
}
}
If you want to create signingApp for live application, So you have follow this code in build.gradle(:app) in android{}.
signingConfigs {
// use for signed apk
release {
storeFile file("../premsingh.jks")
storePassword "app#app"
keyAlias "key0"
keyPassword "app#app"
v1SigningEnabled true
v2SigningEnabled true
}
}
Result will be showing on build Variants and click drop down Button use click of variants.

Change package property in AndroidManifest depending on the applicationId in build time

I am trying to create dynamic package names in my .apk during build time. The problem is that i cannot put a place holder in AndroidManifest.xml as system by default exposes ${applicationId} but this cannot be used.
I cannot also use manifestPlaceholders = [package:""+ applicationId +""] specified in the defaultConfig in build.gradle.
What i tried to do is:
String packageName = System.getProperty("packageName")
defaultConfig {
applicationId packageName
minSdkVersion 19
manifestPlaceholders = [package:""+ packageName +""]
targetSdkVersion 25
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
and the buildTypes:
buildTypes {
release {
println("Building release apk using application id: " + packageName)
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
println("Building debug apk using application id: " + packageName)
if (packageName == null) {
packageName = "com.example.mypackage"
}
applicationIdSuffix ".debug"
versionNameSuffix "-debug"
}
}
What i am trying to achieve here is to get the package name from command line and if someone try to build release without specifing it the build to fail. But even though i do not specify and i execute task assembleRelease i get this message:
Building release apk using application id: null
Building debug apk using application id: null
It still builds the apk and it runs completely fine and this is due to the package provided in Manifest. So my question is how do i dynamically change package in AndroidManifest.xml?

Set value in manifestPlaceholders to applicationId

I am trying to configure some SDK inside application and I am facing this gradle problem, that just gives me a headache. What I have to do is set below value
manifestPlaceholders = [manifestApplicationId: "$applicationId"]
to be something like com.flavorA.debug for debug builds and honestly I have no idea how am I supposed to set this. If I put this section to defaultConfig then I get null inside my manifest file. If I put it to productFlavors section then I only get com.flavorA, so I'm missing buildType suffix.
I was also trying different things like
applicationVariants.each{ variant->
manifestPlaceholders = [manifestApplicationId: "test"]
}
but above doesn't even change the name to test, not mentioning other things.
How am I supposed to solve this with gradle?
You don't need manifestPlaceHolders or the applicationVariants block to achieve this. The applicationId and the package name in the manifest is decoupled, so you simply write:
productFlavors {
pro {
applicationId = "com.example.my.pkg.pro"
}
free {
applicationId = "com.example.my.pkg.free"
}
}
and if you want to change it for the build type:
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
More details here:
applicationid-vs-packagename

How to change the Android app package name when assembling with Gradle?

Is it possible to change the package name of an Android application using Gradle?
I need to compile two copies of the same app, having a unique package name (so I can publish to the market twice).
As a simpler alternative to using product flavours as in Ethan's answer, you can also customise build types.
How to choose between the approaches:
If you need different package names to be able to have both debug and release apks installed on a device, then use the build type approach below, as Gradle plugin docs agree. In this case flavours are an overkill. (I think all projects should by default do this, as it will make life easier especially after you've published to the store and are developing new features.)
There are valid uses for product flavours, the typical example being an app with free and paid versions. In such case, check Ethan's answer and read the documentation too: Configuring Gradle Builds and Gradle Plugin User Guide.
(You can also combine the two approaches, which results in every build variant having distinct package name.)
Build type configuration
For debug build type, and all other non-release types, define applicationIdSuffix which will be added to the default package name.
(Prior to Android Gradle plugin version 0.11 this setting was known as packageNameSuffix.)
android {
buildTypes {
debug {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
}
beta {
applicationIdSuffix '.beta'
versionNameSuffix '-BETA'
// NB: If you want to use the default debug key for a (non-debug)
// build type, you need to specify it:
signingConfig signingConfigs.debug
}
release {
// signingConfig signingConfigs.release
// runProguard true
// ...
}
}
}
Above, debug and release are default build types whose some aspects are configured, while beta is a completely custom build type. To build the different types, use assembleDebug, assembleBeta, etc, as usual.
Similarly, you can use versionNameSuffix to override the default version name from AndroidManifest (which I find very useful!). E.g. "0.8" → "0.8-BETA", as configured above.
Resources:
This example is straight from Xavier Ducrohet's "Google I/O 2013: The New Android SDK Build System" presentation.
Build Types in the User Guide.
Myself I've been using productFlavors so far for this exact purpose, but it seems build type customisation may be closer to my needs, plus it keeps the build config simpler.
Update (2016): I've since used this approach in all my projects, and I think it definitely is the way to go. I also got it included in Android Best Practices guide by Futurice.
You could so something like this
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor1", "flavor2"
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
You can also change the field android.defaultConfig.applicationId if you want to do one-off builds.
Taken from: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration
With the gradle plugin version of 1.0.0+ you have to use applicationId as stated in the migration guide
Renamed Properties in ProductFlavors
packageName => applicationId
Thus in your build.gradle you would now use:
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
}
flavor2 {
applicationId "com.example.flavor2"
}
}
From Ethan's answer, both flavorGroups and packageName both are not available anymore. Below works as of March 2015.
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor"
productFlavors {
flavor1 {
flavorDimension "flavor"
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
flavorDimension "flavor"
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
I did not want to use Flavors, so I found a way to do so with buildTypes. I did this by changing my app/build.gradle file as follows:
defaultConfig {
applicationId "com" // See buildTypes.type.applicationIdSuffix
...
}
...
buildTypes {
debug {
applicationIdSuffix ".domain.name.debug"
...
}
releaseStaging {
applicationIdSuffix ".compagny.staging"
...
}
release {
applicationIdSuffix ".domain.name"
...
}
}
This allows me to have 3 apps next to each other on my devices.
I hope this helps others.

Categories

Resources