I have a placeholder in my AAR's manifest. The AAR builds with no problem when I use assembleRelease/assembleDebug, but when I run my Android instrumentation tests, gradle fails to build the instrumentation APK and throws an error that looks like this
Attribute <blah-blah>#<xyz> at manifestMerger....xml requires a placeholder substitution but no value for <my-place-holder> is provided.
Just for testing purposes (and to confirm whether I can set the value of a placehoder for a specific build type), I set the placeholder value in the debug build type with this:
android { ... buildTypes { debug { manifestPlaceholders = [my-place-holder:"my-value"]
It worked (the release version keeps the placehoder and the placeholder was replaced in the debug version). However, I don't want to (and actually should not) do this because that means my debug version will override the placeholder in the AAR's manifest but I must keep the placeholder in the manifest so it can be overridden by the users of my AAR.
Does anybody knows how to assign manifestPlaceholders ONLY to the instrumentation APK?
Related
I want to build an apk and inside it I need to use release aar inside it.
The aar must be release build since I need to shrink and obfuscate it.
But I would like to print the log for network log to see if my obfuscation will not bother the request payload.
I tried to use System.out.println, but I could not see any log from aar.
Any suggestions?
You can use gradle build config field to enable/disable log print.
Default value for Gradle buildConfigField boolean used across flavors
First create a log wrapper function with a boolean parameter, true means enable log print. And then you can create an init funtcion for your aar, in which you can set log enable parameter.
Meanwhile define a build config field in your app.gradle:
debug {
buildConfigField "boolean", "ENABLE_LOG", "true"
}
release {
buildConfigField "boolean", "ENABLE_LOG", "false"
}
Then just call aar.init(BuildConfig.ENABLE_LOG) on Application.oncreate()
You should be able to turn it on in the manifest/build.gradle. Enable LogCat on Release Build in Android Studio
There have been a few changes to it over the years so you may have to look at more than the accepted answer.
You can also use this library https://github.com/tony19/logback-android
It can create log files on the device, that you can open and inspect.
I want to release my apk on play store. Initially I will release it on alpha, then beta and if everything goes well I will release it on production. Can we define different api endpoint for each in buildType inside gradle. if yes then how? As I just want to change the end point of API I am calling throughout my application. Like if I release my apk on alpha the api that it points will be http://test.alpha.bla.bla
for beta: http://test.beta.bla.bla
for production: http://test.production.bla.bla.
so in this my all version of app (alpha/beta/production) will be having same version code without any need to upload new apk.
Thanks.
I assume that you mean you want 3 different build targets (and thus 3 different uploads to google play):
in your build.gradle you have the android part, in there you can define productFlavors like the following:
productFlavors{
alpha{
buildConfigField 'string', 'server','http://test.alpha.bla.bla'
}
}
But you could also make enums and refere those (instead of the type "string" you would have to specifiy the full package name + enum type , and in the last part (the value), the full package name + enum )
you can then reference the server by using (in java)
BuildConfig.server; //this would be http://test.alpha.bla.bla
I would put it in strings.xml. Each build variant can have its own copy with a different value.
I want to do something like that: gradle build DemoApp, and have DemoApp.apk with application name "DemoApp" as output.
Also, can I change application icon if with the same flow?
And some inner parameters?
Product flavors - not a secret for me. I do not need different configurations, I need to change application name at the build time. For example, I have some Rest API, that allows to pass parameter and return apk with application named as that parameter. The same with icon and other.
Checkout Manifest Merger specifically placeholders. Below is an example of setting the app name in gradle file.
// AndroidManifest.xml
<application
android:label="${applicationName}"
// build.gradle
buildTypes {
release {
minifyEnabled false
manifestPlaceholders = [applicationName: "MobileWorkforce"]
}
The other option is to use #string/app_name and define different string.xml files based upon buildType/flavor.
Given that you don't know how to use flavours properly, a mix of other solutions.
AndroidManifest.xml
<application
android:label="${applicationName}"
MyHttpThing.java
callserver(BuildConfig.ENDPOINT + "/api/v3/", "stuff")
build.gradle
buildTypes {
release {
minifyEnabled false
manifestPlaceholders = [applicationName: myappname]
buildConfigField "String", "ENDPOINT", myendpoint
}
and call with
gradle -Pmyappname=namy_name_name -Pmyendpoint="http://google.com" build DemoApp
Looks like you're looking for Product Flavors, they're exactly for having multiple customized versions of the app with shared codebase. You can customize the icon, as long as any other resource. And yes, the .apk will be named according to the name of the flavor.
In an Android project, the resource ids are fully identified by the application id. For example, if my appid is com.mycompany.myapp, the resource id would be com.mycompany.myapp.R.blah.
In my case, I need to create two versions of the app - beta version and release version. Both the versions may be installed on the same device. This can happen only if the appids are not the same. My strategy is, during the nightly build, I will programmatically modify the manifest file and change the appid to com.mycompany.myappbeta. However, if I do this, I would need to touch a number of source files that are using the resource ids.
I am wondering if there is some token in the manifest file where I can explicitly say how the resource ids be qualified? Regards.
Edit
It turns out app id and package id are indeed two different concepts. I wanted to change the app-id but not the package-id. However, it seems this is not possible under Eclipse. As other posts have pointed out, Gradle build can handle changing the app-id but retaining the package id. I am moving over to Android Studio now.
the resource ids are fully identified by the application id
Technically, they are identified by the package name, from the package attribute in the root manifest.
My strategy is, during the nightly build, I will programmatically modify the manifest file and change the appid to com.mycompany.myappbeta. However, if I do this, I would need to touch a number of source files that are using the resource ids.
Which is why your nightly build should be using Gradle and the Gradle for Android plugin. Then, you skip all of what you described, and instead use build types. Two build types (debug and release) are pre-defined, and if you want to invent another one (e.g., beta), you can. Then, in the build type configuration in your build.gradle file, you use applicationIdSuffix to give non-release builds a distinct suffix. That will be added to the application ID for the purposes of unique installations, but your package name is unaffected, so your resources are unaffected.
For example:
android {
compileSdkVersion 19
buildToolsVersion "21.1.2"
defaultConfig {
versionCode 2
versionName "1.1"
minSdkVersion 14
targetSdkVersion 18
}
signingConfigs {
release {
storeFile file('HelloConfig.keystore')
keyAlias 'HelloConfig'
storePassword 'laser.yams.heady.testy'
keyPassword 'fw.stabs.steady.wool'
}
}
buildTypes {
debug {
applicationIdSuffix ".d"
}
release {
signingConfig signingConfigs.release
}
beta.initWith(buildTypes.release)
beta {
applicationIdSuffix ".beta"
debuggable true
}
}
}
Here I:
Give the debug build type an application ID suffix of .d
Leave the release build type along from the standpoint of an application ID suffix
Create a new beta build type, cloned from the release build type, where I give it a .beta application ID suffix and mark it as debuggable
However, if I do this, I would need to touch a number of source files that are using the resource ids.
No, you will not. You just need to change package id in your Manifest file only, ensuring however all services and activities listed in manifest file are using full class path, i.e.:
android:name="com.mycompany.myapp.MainActivity"
not just shortened notation:
android:name=".MainActivity"
as this make your app not working when package Id will not match with your code packages.
Hey I am trying to statically define String values that change according to the configuration I am running. So if I run a test configuration, it uses the test API url, but if I run a regular build, it statically sets the real API URL.
I am using two strings files right now, one in the main folder and one in the androidTest folder in Android Studio. This works well for getting different Strings per configuration, but I'de like to do it statically rather than dealing with Resource fetches.
Is this possible?
I have seen this answer for ANT, but I am not sure how to do it with Gradle.
You can generate gradle constants like this:
build.gradle
android {
buildTypes {
debug {
buildConfigField "String", "FOO", "\"foo\""
}
release {
buildConfigField "String", "FOO", "\"bar\""
}
}
}
And access them in your code through BuildConfig.FOO
Note you may need to clean and/or restart your IDE for the to come in to effect.