Butterknife 8.8.0 introduced the new processor option butterknife.debuggable (link to changelog). By default, it's true. Where do I set it to false in my build.gradle file? I tried placing it in my defaultConfig, but I keep getting the error:
Could not get unknown property 'butterknife'...
Looks like Butterknife mirrors the debuggable attribute of your current config. So setting debuggable inside your defaultConfig or other build type should also set butterknife.debuggable.
EDIT: My initial answer was incorrect. Add this to your Gradle build type to modify the butterknife.debuggable flag:
javaCompileOptions.annotationProcessorOptions.arguments['butterknife.debuggable'] = 'false'
Related
I am migrating to Kotlin dsl and I can't set buildFeatures property databinding any more. It is missing from AppExtension class. It is happening in dynamic feature module
Any suggestions?
Before in Groovy worked
android {
buildFeatures {
dataBinding = true
}
}
Kotlin is not working either the same syntax or
buildFeatures.dataBinding = true
Attaching some screenshots.
The error is
Unresolved reference: dataBinding
After submitting a ticket to Google the answer is to use
https://issuetracker.google.com/issues/193452960
android.dataBinding.isEnabled = true
Based on the dev reply marking it as deprecated is a bug and should not be thee case in kts.
From the ticket:
Sorry for the mixed messages about build features, we realized that it made more sense to put the enable flag for features next to the feature itself. The plan is that the supported path will be:android.dataBinding.isEnabled = true
Which works today in kts, but is currently incorrectly marked as deprecated.
You could try to upgrade your AGP.
I'm new to React Native. The task at hand is to set my Google API key in AndroidManifest.xml without exposing it, when pushed to GitHub.
I set up an environment variable called API_KEY, but however I want to access it in the .xml, I get an error when trying to spin up the dev server.
So far I tried:
android:value=${env.API_KEY}
android:value="${env.API_KEY}"
android:value="${API_KEY}"
Thank you!
Based on the second comment (from kenmistry), the solution that worked for me was indeed to create a placeholder in build.gradle, but since, for whatever reason, configuring and referring a .env file did't work, I invoked my environment variables like so in build.gradle:
manifestPlaceholders = [API_KEY: "$System.env.API_KEY"]
and accessed it in the .xml as suggested by kenmistry:
android:value="${API_KEY}"
assuming that you have defined the key in your .env file, you can set that up on build.gradle as manifestPlaceholders.
android {
defaultConfig {
manifestPlaceholders = [API_KEY: "$process.env.your_key"]
}
...
}
on your AndroidManifest.xml,
android:value="${API_KEY}"
I’m working on a multiplaform project, iOS and JVM (I’m not targeting Android directly). Depending on the build type (debug or release) I want to configure the logging level (i.e. to print only errors in release). Since there is no a BuildConfig class available, how can I know from commonMain the build type?
Not a direct answer to the question, but for android/ios one can define a property like this:
in commonMain:
expect val isDebug: Boolean
in androidMain:
actual val isDebug = BuildConfig.DEBUG
in iosMain:
actual val isDebug = Platform.isDebugBinary
It is not possible right now for all possible targets. Build type is resolved only for android.
But you can create two versions of the module e.g. module and module-debug.
Then declare in module:
const val IS_DEBUG = false
in module-debug:
const val IS_DEBUG = true
Finally in the resulting application or module gradle configuration you can declare dependency on what you need. E.g.:
if (DEBUG_ENV) // you need to set DEBUG_ENV from property or environment variable
implementation(project(":module-debug"))
else
implementation(project(":module"))
or for android:
debugImplementation(project(":module-debug"))
releaseImplementation(project(":module"))
This way you can change logic using IS_DEBUG constant for every target or can create even completely different implementations of something in debug and release modules.
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?
I have got the following trouble: I have installed SonarQube and Android Plugin with "Android Lint" Quality Profile. When I execute my build.gradle script with "Android Lint" profile, sonar-runner plugin works good, but in SonarQube I can see no matching issues found, just zero.
Nevertheless, when I include another profile –not "Android Lint"– I can see a lot of issues. Also in my android SDK when apply it's own lint I can see 157 issues. What it can be?
sonar - version 3.7.4;
android plugin - version 0.1
Your sonar.sources property should point to the root of AndroidManifest.xml file. E.g. if your AndroidManifest.xml file is located in src/main then your build.gradle file should contain:
sonarRunner {
sonarProperties {
...
property "sonar.sources", "src/main"
property "sonar.profile", "Android Lint"
...
}
}
If you need more paths in sonar.sources you can put them as a comma-separated list.
You can find how Sonar Android Plugin determines whether to run the analysis in its source code.
change your sonar properties like this:
apply plugin: "org.sonarqube"
sonarqube {
properties {
property "sonar.projectName", "appa"
property "sonar.projectKey", "appa_app"
property "sonar.projectVersion", "1.0"
property "sonar.analysis.mode", "publish"
property "sonar.language", "java"
property 'sonar.sourceEncoding', "UTF-8"
property "sonar.sources", "./src/main"
//property "sonar.exclusions", "**/*Entity.java"
// property "sonar.exclusions", "src/main/java/com/apparkb/model/**, **/*Entity.java"
property "sonar.host.url", "http://192.168.21.33:9000"
property "sonar.login", "admin"
property "sonar.profile", "testlint"//use your quality profile instead
property 'sonar.import_unknown_files', true
property "sonar.android.lint.report", "./build/outputs/lint-results-debug.xml"
property "sonar.password", "admin"
property "sonar.java.binaries", "build/"
}
}
For creating lint-results-debug.xml you will have to run the below command on studio terminal:
./gradlew lint
It will generate the missing XML report. Be carful, it can generate a report for each build variant (Debug by default will generate build/outputs/lint-results-debug.xml). So you can call lintDebug, lintRelease... dependings on your build variant.
And change the lint properties to:
lintOptions { // set to true to turn off analysis progress reporting by lint
quiet true
// if true, stop the gradle build if errors are found
abortOnError false
// do not ignore warnings
warningsAsErrors true
}
now if you run
./gradlew sonarqube
you will get the results shown its actually the local file report that's actually getting hosted upon the server
Unfortunately if you merely point sonar.sources to src/main, you're going to get issues with all your source because you most likely don't mave minSdkVersion and targetSdkVersion set (it comes from gradle). I've tried setting my source to be some thing like:
build/intermediates/bundles/release,src/main/java
But I still get an inordinate amount of (invalid) errors due to API levels.