I use gradle to build app. And I add a suffix to the packageName of my debug version. Just as following:
buildTypes {
debug {
packageNameSuffix ".debug"
}
}
However, one of the libs I use can't work with this.
I think the lib uses code like this to get the R class:
drawable = Class.forName(this.context.getPackageName() + ".R$drawable");
And it throws java.lang.IllegalArgumentException: ResClass is not initialized.
The correct package for R is com.xxx.R$drawable. Since I add a suffix to the package, when the lib want to get the class using reflection it gets com.xxx.debug.R$drawable.
Is there any way to fix it? BTW I can't modify the code of the lib because it is a jar file.
Not sure if it can help you, I have seen a similar problem in different circumstances.
The R class is just a class, for example, when the R package name is different from the current app package name, import com.xxx.yyy.R helps.
Probably you can create a missing class as an ancestor of the class with the correct package name. This, of course, will break your non-debug build, so you will have to add this class for debug builds and remove it for non-debug ones.
Related
My project has different build types i.e. debug, beta and production and also have different product flavors i.e. QA and Integration. I have defined
a
buildConfigField 'int', 'APP_THEME', 'R.style.AKTheme'
in the productFlavors to have a separate theme for each flavor. The generated BuildConfig.java for app source set have the APP_THEME field and it is working as expected.
Recently I have started writing instrumentation tests for my app. When I try to run these tests Android studio gives me the error that can not resolve AKTheme i.e.
final int APP_THEME = R.style.AKTheme in the generated BuildConfig.java for the test source set.
It seems that R.style.AKTheme is not accessible to the generated BuildConfig.java file (test source set). I searched over internet but didn't find any help.
R.style.AKTheme is a reference, not a value, while in BuildConfig you can only use values.
There are couple of ways to achieve what you want:
Use the String name of the style in BuildConfig:
buildConfigField 'String', 'APP_THEME', '"AKTheme"'
and then in code to get the style res id:
int style = context.getResources().getIdentifier(BuildConfig.APP_THEME, "style", context.getPackageName());
Now you can use style.
You can use different source-sets.
If you are using different buildtypes, you can create a directory for that build type, and put any different resources specially for that build type in that directory. The directory should be created in the same directory as main sources directory, and named exactly the same as the buildType. Details: https://developer.android.com/studio/build/build-variants
I had quite the same issue. I had this in my build.gradle to get the right ssl certificate depending on the env. :
buildConfigField 'int', 'SSL_CERTIFICAT_RAWRES_', 'R.raw.devcert'
This was working to build and run the project, but I faced an issue when I wanted to run the task : "compileDebugAndroidTestJavaWithJavac" (used for sonarqube in my case). The compiler didn't found the resource file R when he automatically generates the buildConfig file.
The solution was to put a String to identify my certificate file "devcert" in the build.gradle instead of using directly the resInt "R.raw" :
buildConfigField 'String', 'SSL_CERTIFICAT_RAWRES_STRING', '"devcert"'
and then in my code, I get the raw file certificate like this :
final int raw = context.getResources().getIdentifier(BuildConfig.SSL_CERTIFICAT_RAWRES_STRING, "raw", context.getPackageName());
That way, the generated buildConfig found correctly the String identifier to retrieve the wanted raw file using the code above.
I found my answer here: https://developer.android.com/studio/test#create_instrumented_test_for_a_build_variant
For my case my test project and my main project is referencing a different package name, e.g. at the top of BuildConfig.java one referencing to package 'com.xxx.xxx' while one is referencing to 'com.xxx.xxx.test'
adding the line
testApplicationId = "com.xxx.xxx"
in defaultConfig in app level build.gradle file solves the issue for me
I've met several proguard examples with these lines:
# Keep the BuildConfig
-keep class com.example.BuildConfig { *; }
I've run app with and without this line (of course, with my package) and haven't found any differences.
I've also looked in generated/.../BuildConfig.java and there are no changes too.
What for do I need to keep my BuildConfig in ProGuard?
Thanks!
BuildConfig contains a number of useful values that are set at compile time. Specifically these:
boolean DEBUG – if the build is debuggable.
int VERSION_CODE
String VERSION_NAME
String APPLICATION_ID
String BUILD_TYPE – name of the build type, e.g. "release"
String FLAVOR – name of the flavor, e.g. "paidapp"
You can also set your own config values, e.g. different urls for testing and production, and retrieve them from the BuildConfig file instead of maintaining your own Config.java file. This can be done by adding buildConfigFields to your gradle buildTypes like so:
buildTypes {
debug {
buildConfigField "boolean", "SOME_VAR", "true"
}
release {
buildConfigField "boolean", "SOME_VAR", "false"
}
}
So to answer your question, as far as I know you don't have to keep the file, but it's good practice to do so and to use it for your config needs.
As with any other class, you need to -keep the class if you're accessing it indirectly via reflection so ProGuard won't obfuscate it or optimize it away as unused.
Most often the access patterns with BuildConfig are direct without reflection so in those cases it's fine to have ProGuard process your BuildConfig, too.
Some crash reporter libraries like ACRA does access BuildConfig via reflection, so if you use one and want to have info from it in your crash reports, you should -keep it.
I'd like to stamp some variable generated from gradle (in my case it's User Agent used later with HTTP requests) to later be able to distinguish which developer build the app (for example if some developer made a mistake and his app is DDoSing the server).
So for now I can distinguish release from debug with:
buildTypes {
debug {
buildConfigField "String", "USER_AGENT", "\"Android-debug\""
}
release {
buildConfigField "String", "USER_AGENT", "\"Android-release\""
}
}
But for the debug I'd like to add something to know who built the app instance, it may be git login, machine name, or something else.
A gradle build file is actually Groovy code, and you're free to put whatever you want in it. You just have to make sure that the code runs before it would be used in the DSL that describes the build. So if you want to grab something from the system, just write the Groovy code to do that. Groovy is a lot like Java, and you have the full JDK to work with at runtime, so it should be easy to get started.
If you want to access things about the build machine and environment, you might have to shell out to different commands in order to gather that data. Populate some variables with that data. Then use buildConfigField as you already are to drop those values into BuildConfig.java.
Bear in mind that you might want to provide some value in both debug and release so they both generate the same BuildConfig symbols. Otherwise your app might not compile in one config or the other.
BTW. You can tell the difference between debug and release with properties that are already added to BuildConfig, so you don't need to add anything more to tell the difference. Lines like these will always appear (look in the generated BuildConfig.java to see for yourself):
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String BUILD_TYPE = "debug";
When I add a packageNameSuffix to my build.gradle debug build type (see https://plus.google.com/108967384991768947849/posts/XGXH3arvbrK), all of my Robolectric tests are failing due to the following:
Caused by: android.content.res.Resources$NotFoundException: Unable to find resource ID #0x7f050000
at org.robolectric.shadows.ShadowResources.getResName(ShadowResources.java:354)
at org.robolectric.shadows.ShadowResources.openRawResource(ShadowResources.java:387)
at android.content.res.Resources.openRawResource(Resources.java)
at com.myapp.utilities.CSVUtility.parseRawResourceCSV(CSVUtility.java:38)
The problem seems to be that the raw folder src/main/res/main no longer being found. This folder contains a csv which is parsed at application start... which is where the tests go boom.
Architecture/data restructuring suggestions aside (I know CSV may not be the best way to get this data loaded at app start), does anyone know how I might remedy this problem?
Edit: I tried moving the file to the assets folder instead, and then my tests failed on a Context.getString() call. Resources look to be getting completely hosed when adding packageNameSuffixes.
Edit: tmurakami posted on the github issue - https://github.com/robolectric/robolectric/issues/1001#issuecomment-42740897
I've copied the full response:
Try using this gradle snippet.
This works fine in my environment.
def hasLibraryVariants = android.hasProperty('libraryVariants')
def variants = hasLibraryVariants ? android.libraryVariants : android.applicationVariants
tasks.withType(Test).whenTaskAdded {
it.systemProperty 'android.package', variants.iterator().next().processResources.packageForR
}
The original package name has been stored in the following fields of any variant:
variantData.variantConfiguration.originalPackageName
processResources.packageForR
generateBuildConfig.buildConfigPackageName
However these are internal only, so might become inaccessible in the future.
If you don't want to use these fields, try the following snippet:
tasks.withType(Test).whenTaskAdded {
it.systemProperty 'android.package', android.defaultConfig.packageName
}
To use this, you need to add the main package name in the 'android.defaultConfig' section.
android {
defaultConfig {
packageName 'main.package.name'
}
}
Looks like I need to add an android.package system property for the package name. See this issue conversation on Github - https://github.com/robolectric/robolectric/issues/1001
I'm converting my app to use gradle, and I'm trying to use the buildTypes. I have a Constants class which I wish to modify for my release build. So I have a file at src/main/java/my/package/name/Constants.java and at src/release/java/my/package/name/Constants.java.
When I try to build this, gradle tells me the build failed on the Constants file in my release buildtype, with the error that it's a duplicate class.
I also tried adding a different sourceSet for this in my build.gradle like this:
sourceSets {
main {
java.srcDirs = ['src/main/java'];
//...
}
release {
java.srcDirs = ['src/release/java'];
}
}
But this still gives me the same error. So I'm wondering, what am I doing wrong here?
You can not have a class in main and release. You need to split it into something like debug and release.
gradle will merge the source sets for each buildType with main.
This is the reason, why the class gets duplicated in your release build.
So the rule is: put a class into main, or in every buildType but not both.
The answer from "fix" helped me on the way, but I got an error from the main Gradle, saying a constant was missing (in my class Config). This since I had my class only in paid and free version and not in main. Could not find the Config class.
Im not sure if this is a bug in Studio... I finally solved it with the following:
buildTypes {
release {
...
buildConfig "public static final boolean XYZ = false;"
}
}
And the instead of using my Config.XYZ class constant I used buildConfig.XYZ