IssueTracker

The issue is that Jetifier modifies jars and does not remove signatures. Below is the original class:

Classfile /tmp/non-jetified/org/bouncycastle/jce/provider/ExtCRLException.class
  Last modified Mar 1, 2015; size 362 bytes
  MD5 checksum 3968a716f9e60e1ad36c34157bd0239f
class org.bouncycastle.jce.provider.ExtCRLException extends java.security.cert.CRLException
  minor version: 0
  major version: 49
  flags: ACC_SUPER
Constant pool:
   #1 = Utf8               <init>
   #2 = Utf8               cause
   #3 = Utf8               getCause
   #4 = Utf8               java/security/cert/CRLException
   #5 = Utf8               org/bouncycastle/jce/provider/ExtCRLException
   #6 = Class              #4             // java/security/cert/CRLException
   #7 = Class              #5             // org/bouncycastle/jce/provider/ExtCRLException
   #8 = Utf8               Ljava/lang/Throwable;
   #9 = Utf8               (Ljava/lang/String;)V
  #10 = Utf8               ()Ljava/lang/Throwable;
  #11 = Utf8               (Ljava/lang/String;Ljava/lang/Throwable;)V
  #12 = NameAndType        #2:#8          // cause:Ljava/lang/Throwable;
  #13 = NameAndType        #1:#9          // "<init>":(Ljava/lang/String;)V
  #14 = Fieldref           #7.#12         // org/bouncycastle/jce/provider/ExtCRLException.cause:Ljava/lang/Throwable;
  #15 = Methodref          #6.#13         // java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
  #16 = Utf8               Code
{
  java.lang.Throwable cause;
    descriptor: Ljava/lang/Throwable;
    flags:

  org.bouncycastle.jce.provider.ExtCRLException(java.lang.String, java.lang.Throwable);
    descriptor: (Ljava/lang/String;Ljava/lang/Throwable;)V
    flags:
    Code:
      stack=2, locals=3, args_size=3
         0: aload_0
         1: aload_1
         2: invokespecial #15                 // Method java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
         5: aload_0
         6: aload_2
         7: putfield      #14                 // Field cause:Ljava/lang/Throwable;
        10: return

  public java.lang.Throwable getCause();
    descriptor: ()Ljava/lang/Throwable;
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: getfield      #14                 // Field cause:Ljava/lang/Throwable;
         4: areturn
}

One processed with Jetifier:

Classfile /tmp/jetified/org/bouncycastle/jce/provider/ExtCRLException.class
  Last modified Oct 14, 2019; size 362 bytes
  MD5 checksum 76bc557706ee3480e53d88b21316913f
class org.bouncycastle.jce.provider.ExtCRLException extends java.security.cert.CRLException
  minor version: 0
  major version: 49
  flags: ACC_SUPER
Constant pool:
   #1 = Utf8               org/bouncycastle/jce/provider/ExtCRLException
   #2 = Class              #1             // org/bouncycastle/jce/provider/ExtCRLException
   #3 = Utf8               java/security/cert/CRLException
   #4 = Class              #3             // java/security/cert/CRLException
   #5 = Utf8               cause
   #6 = Utf8               Ljava/lang/Throwable;
   #7 = Utf8               <init>
   #8 = Utf8               (Ljava/lang/String;Ljava/lang/Throwable;)V
   #9 = Utf8               (Ljava/lang/String;)V
  #10 = NameAndType        #7:#9          // "<init>":(Ljava/lang/String;)V
  #11 = Methodref          #4.#10         // java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
  #12 = NameAndType        #5:#6          // cause:Ljava/lang/Throwable;
  #13 = Fieldref           #2.#12         // org/bouncycastle/jce/provider/ExtCRLException.cause:Ljava/lang/Throwable;
  #14 = Utf8               getCause
  #15 = Utf8               ()Ljava/lang/Throwable;
  #16 = Utf8               Code
{
  java.lang.Throwable cause;
    descriptor: Ljava/lang/Throwable;
    flags:

  org.bouncycastle.jce.provider.ExtCRLException(java.lang.String, java.lang.Throwable);
    descriptor: (Ljava/lang/String;Ljava/lang/Throwable;)V
    flags:
    Code:
      stack=2, locals=3, args_size=3
         0: aload_0
         1: aload_1
         2: invokespecial #11                 // Method java/security/cert/CRLException."<init>":(Ljava/lang/String;)V
         5: aload_0
         6: aload_2
         7: putfield      #13                 // Field cause:Ljava/lang/Throwable;
        10: return

  public java.lang.Throwable getCause();
    descriptor: ()Ljava/lang/Throwable;
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: getfield      #13                 // Field cause:Ljava/lang/Throwable;
         4: areturn
}


Changes in the constants pool cause changes in the code (indices change), which causes different MD5 checksums. This means that signatures will not match any more.

This started happening in 3.6.0-beta01 because we are using Jetifier with copyUnmodifiedLibsAlso=true flag (previously it was false).

@Chris You can work around this by updating gradle.properties with:

android.jetifier.blacklist=.*bcprov.*

This will avoid Jetifying the bouncycastle library.

Thanks Ivan!

Pending fix in: https://android-review.googlesource.com/c/platform/frameworks/support/+/1151460

did this fix make it in for 3.6?

Jetifier 1.0.0-beta08 was released and has a fix for this.

To avoid waiting for new Android Studio you can workaround this in the meantime by forcing usage of a new version of jetifier in gradle:
buildscript {
   dependencies {
       classpath 'com.android.tools.build:gradle:x.y.z'
       classpath 'com.android.tools.build.jetifier:jetifier-processor:1.0.0-beta08' // <- Add this
   }
}

Jetifier 1.0.0-beta08, which has the fix for this issue, will be integrated into AGP 3.6.0-rc01 and 4.0.0-alpha06: https://android.googlesource.com/platform/tools/base/+/ef5e56702b626b6be642ecce7d0078b7b1a81bcb

Hi,

I have an android project using a java lib in Android Studio. As a first workaround I tried adding the following to my java lib test configuration,
test {
runtimeClasspath += files("${buildDir}/resources/test")
}
it didn't work (can't understand why as it was expected that that dir would be added to the classpath for test execution)

The one below is working ok though, running from Android Studio directly (run or debug a particular test or suite), or using gradlew check.

// JUnit tests missing test resources in classpath >> https://code.google.com/p/android/issues/detail?id=64887
// This task copies the resources to a folder that exists on the classpath
task copyTestResources(type: Copy) {
    from "${projectDir}/src/test/resources"
    into "${buildDir}/classes/test/resources"
}
processTestResources.dependsOn copyTask

I'm accessing resources from my tests using
InputStream s = ClassLoader.getSystemResourceAsStream("resources/test.json");

it's ok as a workaround but I really though the first one would succeed.

cheers,

I had to change the above workaround a little to work for me:

task copyTestResources(type: Copy) {
    from "${projectDir}/src/test/resources"
    into "${buildDir}/classes/test"
}
processTestResources.dependsOn copyTestResources

My tests now run fine both in Android Studio and using the gradle command-line tool.

The JavaModel in IdeaGradleFacet now has the project's output resource folders. Assigning back to Siva.

It turns out that IntelliJ 13 does not support having multiple classpaths during execution. When using IntelliJ to build and run tests, the IntelliJ builder copies all the resources into the output folder. This is exactly what was suggested in Comment #13 by ralf@.

So the temporary workaround is to follow Comment #13.

The good news is that IntelliJ 14 provides native support for running Gradle tests: http://youtrack.jetbrains.com/issue/IDEA-116904

We will probably switch over to using IntelliJ 14 once it is more stable, probably sometime in Sep/Oct of this year. Until then, please follow the workaround in Comment #13.

journeyapps - can you tell us exactly where you added this in your gradle file?

task copyTestResources(type: Copy) {
    from "${projectDir}/src/test/resources"
    into "${buildDir}/classes/test"
}
processTestResources.dependsOn copyTestResources

Hi,
You need to add that to your Java library gradle file. At the root level,
not inside any other configuration.
Additionally, I would recommend adding 'resources' to the 'into' folder,
i.e.
into "${buildDir}/classes/test/resource s"
so your resources are kept tidy...

I can confirm that the workaround in comment #13 is working.

Now we can run unit tests both via cmd line and Android Studio.
Thanks! :)

Is this still an issue for Android Studio v0.8.14?

Yes, this is still an issue in Android Studio v0.8.14.

The work-around from #13 still works.

"The work-around from #13 still works."

From my perspective it's not enough. Its not supported from google dev team. So this 'feature' / 'work-around' may be changed and it'll stop work, and you will not know when it'll be fixed cuz it never was official functionality. I don't want to use work-arround an some day update gradle-plugin or Android-Studio and this will stop work. I'm more java developer than Android developer. I'm used to write JUnit tests with spring and whole stack of libraries placed on servers. Im looking forward for same functionality on Android projects.

Has there been any progress on this?
I'm currently using  Android Studio 0.8.14 and IntelliJ 14 with Android Gradle Tools plugin, and I cannot include resources from the 'androidTest' path into a unit test build. Am I doing something wrong?

Source is fine, 'src/androidTest/java' shows up fine, and only in instrumented tests.  Resource items from 'src/androidTest/res' do not, and unit testing resources like mock JSON response files, Fragment test containers and the like need to be put into the main path.

Reading the documentation seems to imply that it should just be automatic, and there is no explicit statement of 'here is a case where it works' or 'this is a known problem'...

At the risk of sounding snarky, please fix this first and skip the unnecessary churn like 'runProguard' to 'minifyEnable'  At a minimum, please put this issue in the 'Known Issues' section.  Simply being silent on it isn't a good way to go.

This issue will not be fixed until (at the very least) Studio moves to using IJ 14, which itself won't happen before Studio 1.2. Until then, please use the suggested workaround in Comment #13.

I've added this to the known issues at https://sites.google.com/a/android.com/tools/knownissues

A minor update: The hardcoded paths can be removed from the task, giving a slightly cleaner workaround:

task copyTestResources(type: Copy) {
    from sourceSets.test.resources
    into sourceSets.test.output.classesDir
}
processTestResources.dependsOn copyTestResources

[Comment deleted]

Is there a working Android instrumented test posted anywhere that has test resources segregated?

Following this workaround, I get the following error:
"Error:(57, 0) Could not find property 'test' on SourceSet container."

Enclosed is the app's build.gradle file.

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.0.0'
    }
}

apply plugin: 'com.android.application'

repositories {
    jcenter()
}

android {
    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
        applicationId "com.foo.client.app"
        minSdkVersion 15
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:support-v4:21.0.3'
    compile 'com.android.support:appcompat-v7:21.0.3'
}

task copyTestResources(type: Copy) {
    from sourceSets.test.resources
    into sourceSets.test.output.classesDir
}
processTestResources.dependsOn copyTestResources


When attaching to the 'Client' project level (app's parent project in Android Studio) build.gradle file, I need to use like this:

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:1.0.0'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

apply plugin: 'java'

task copyTestResources(type: Copy) {
    from sourceSets.test.resources
    into sourceSets.test.output.classesDir
}
processTestResources.dependsOn copyTestResources



Running 'gradle clean test' produces a clean run, but following with 'gradle installDebugTest' fails with missing resources.

Any working examples?
Does this only work for non-instrumented tests (i.e. Robolectric, etc)?

Thanks.

[Comment deleted]

[Comment deleted]

[Comment deleted]

Hello.

This issue occured on ADT with Eclipse until now.(yr 2015)
Mean that not only studio issue seem that general tool issue.

Are you google ppl really aware of what the problem is?

How to reproduce is that
- Project A as library with the string resources
- Project B as main app which calling Project A
- Project B only call a Project A's method which contains 'getString()' within Project A's resource.
- And Test Project.

I hope that you ppl get the sight of the problem.

The workaround does not work anymore.

processTestResources is provided by the Java plugin, but we can't use it anymore:

    Error:The 'java' plugin has been applied, but it is not compatible with the Android plugins.

And when removing the java plugin:
    Error:(84, 0) Could not find property 'processTestResources' on root project 'FDC-Android'.

Seriously? Is it so hard to provide Junit Testing from google. Now my level of disappointment grow fast.

As mentioned earlier workaround is not enought. Now some wokrarrounds not work anymore.

REAL situation:
There was a bug in some app.
1. checkout tag.
2. Import in Android studio.
2.1 Android will not import cause it was old tag (Develop on older verison of Android Studio- in that time - the latest).
2.1.1 Need to update version of build tool to even import project
2.1.2 Now workarround stoped work.
So now I have bug to fix but cant even import project to IDE.

Pls stop focus on some fancy features.

And implement something core like Testing applictions.

JUnit tests Mockito are from ages in plain old java. Please provide that little functionality on Android Studio. Now Development/Maintenence of project is like big mess.

Now some people are backuping Android Studios to maintain/fix old versions of applications.

Did you guys try version 1.1.0-rc1 of the Gradle Android plugin [1] which adds native unit test support [2] and probably has changed a bunch of test related internals?

[1] http://tools.android.com/tech-docs/new-build-system
[2] http://tools.android.com/tech-docs/unit-testing-support

Looks Promissing

1.1.0-rc1 doesn't fix the issue (https://code.google.com/p/android/issues/detail?id=136013)

Does this issue extend to resources in the main (rather than test) directory? I cannot seem to pick up resources in my java library that should be there.

Probably yes, see my workaround in the other issue (https://code.google.com/p/android/issues/detail?id=136013#c19). Fix is targeted for 1.2.

I have similar issue with project with two submodules (apk and jar).

In jar project in JUnit tests I cant get resource from production code (jar_module/src/main/resources/**)

When I run test from gradle its fine. But when I run JUnit production resources from jar project are invisible. This will be fixed in 1.2?

This is still present in 1.2RC3.

Hi guys, since this issue still happens with Android Studio 1.2 (AI 141-1890965) with TestNG, here's workaround:
1. Add the copyTestResources task to your build.gradle from answer #26, but without dependsOn line.
2. Open Studio Run Configurations / Defaults / JUnit|TestNG.
3. Add 'Before launch' task / Gradle / copyTestResources (leave 'Gradle project' empty for multi-project).

Now Android Studio will automatically run the copyTestResources task whenever you launch the test from it.

Smart way for project with flavors:

afterEvaluate {
  /* Include resources. See: https://code.google.com/p/android/issues/detail?id=64887#c13 */
  project.android.productFlavors.each { f ->
    project.android.buildTypes.each { b ->
      /** compose dynamic tasks */
      def tName = "copy${f.name.capitalize()}${b.name.capitalize()}TestResources"
      project.task(tName, type: Copy) {
        description = "Make resources available for test: test${f.name.capitalize()}${b.name.capitalize()}."
        group = 'Unit Testing'

        from project.android.sourceSets["test"].resources.srcDirs
        into "${project.buildDir}/intermediates/classes/test/${f.name}/${b.name}"
      }

      tasks.matching { it.name.equalsIgnoreCase("test${f.name}${b.name}") }.each {
        it.dependsOn tName
      }
    }
  }
}

[Comment deleted]

I found this blog post extremely helpful and was able to get them working...

https://www.bignerdranch.com/blog/triumph-android-studio-1-2-sneaks-in-full-testing-support/

I have a project using the default project structure of Android Studio, using Android Studio v1.2. I tried all the proposed solutions in this thread to no avail and spent a couple days fruitlessly trying to find a solution. For anyone still struggling here's what worked for me:

Grab this file and put it in your app module:
https://github.com/nenick/AndroidStudioAndRobolectric/blob/master/app/build.workaround-missing-resource.gradle

Update the build.gradle file in the module to apply the workaround:
apply from: 'build.workaround-missing-resource.gradle'

Thats it! Resources should now be loaded when running tests from within Android Studio.

Obviously if you've been hacking about with various fixes above then just remember to restore your build.gradle files above first to a clean state and remove any modifications made to junit run configurations.

Assuming you are loading a file called testdata.json located in src/test/resources then any of the following will resolve the file:
        ClassLoader.getSystemResourceAsStream("testdata.json")
        getClass().getClassLoader().getResourceAsStream("testdata.json")
        getClass().getResourceAsStream("/testdata.json")

Full credit to Nico Küchler for this elegant fix; it just about saved me from going completely insane!

I can confirm that #46 has worked for me. Thank you and Nico Küchler! It has saved me so much time, as it was driving me crazy trying to figure it out.

One caveat for me though, is that I am testing a module which is a library project, so the build variants must use libraryVariants not applicationVariants in
build.workaround-missing-resource.gradle

    // Copy must be done for each variant.
    def variants = android.libraryVariants.collect()

Put test resources in src/test/resources and fetch them just using the filename and it works!

The solution above (#13, #46, etc) does not take into account that the java resources in dependency module within the same project.

I build a project the demonstrate the problem and have a proposed solution:

https://github.com/hkhc/android-studio-unit-test-resource-issue-demo

It contains a piece of gradle script to copy the java resources within the dependent AARs/JARs to test classes directory.

gradle.projectsEvaluated {
    // Base path which is recognized by android studio.
    def testClassesPath = "${buildDir}/intermediates/classes/test/"
    // Copy must be done for each variant.
    def variants = android.applicationVariants.collect()

    variants.each { variant ->
        def variationName = variant.name.capitalize()

        // Get the flavor and also merge flavor groups.
        def productFlavorNames = variant.productFlavors.collect { it.name.capitalize() }
        if (productFlavorNames.isEmpty()) {
            productFlavorNames = [""]
        }
        productFlavorNames = productFlavorNames.join('')

        // Base path addition for this specific variant.
        def variationPath = variant.buildType.name;
        if (productFlavorNames != null && !productFlavorNames.isEmpty()) {
            variationPath = uncapitalize(productFlavorNames) + "/${variationPath}"
        }

        configurations.compile.each {
            String p = it.absolutePath
            if (p.endsWith('.jar')) {
                copy {
                    from zipTree(p)
                    into file("${testClassesPath}/${variationPath}")
                    exclude '**/*.class'
                }
            }
            else if (it.absolutePath.endsWith('.aar')) {
                FileTree t = zipTree(it.absolutePath)
                t.each {
                    String p2 = it.absolutePath
                    if (p2.endsWith('jar')) {
                        copy {
                            from zipTree(p2)
                            into file("${testClassesPath}/${variationPath}")
                            exclude '**/*.class'
                        }
                    }
                }
            }
        }

        copy {
            from project.android.sourceSets["test"].resources.srcDirs
            into "${project.buildDir}/intermediates/classes/test/${variationPath}"
        }

    }
}

It has been almost a year since this was added as a "known issue" since then, Android Studio has adopted IntelliJ 14. Also, it is pretty customary for a reasonably sized test harness to require a number of resource files (such as sample JSON data sets).

Following "convention over configuration" we should be able to just place those files in src/test/resources and have them available to our unit tests, without requiring extra configuration.

Is there any update on this bug? Are there plans to resolve it?

Issue 36949180 was opened in January 2014. In September 2014, it was marked as a duplicate of issue 36949180 and duly closed.

Issue 36949180 was opened in September 2014: "This is a general bug encapsulating all the features needed (meant to flag external reports as duplicate of this one).".

The description of 75991 is vague enough to be classified as ongoing and never going to be resolved.

So my understanding is no there are no plans to resolve the issue on this page (64887).

Maybe someone at Google has a better insight into the issue processing process?

[Comment deleted]

Version of Android Studio 2.0 beta 7
OS version: OSX 10.11.1
Java JRE/JDK version: jdk1.7.0_79

I'm using a java module inside android app structure. Above issue still occurs in the module. Resources not are copied into classes/tests, thus I use the workaround which is provided.

Android Studio 2.1.2. problem still happening.

Android Studio 2.2, same result. In fact, even resources under main were not being added to the classpath, so I had to add:

task copyTestResources(type: Copy) {
    from "${projectDir}/src/test/resources"
    into "${buildDir}/classes/test"
}
processTestResources.dependsOn copyTestResources
task copyMainResources(type: Copy) {
    from "${projectDir}/src/main/resources"
    into "${buildDir}/classes/main"
}
copyTestResources.dependsOn copyMainResources

Hope this is fixed soon...

I got it working without having to copy files:

dependencies {
    ...
    runtime files('build/resources/main')
    // Not tested.
    testRuntime files('build/resources/test')
    ...
}

"Android Studio 2.2, same result. In fact, even resources under main were not being added to the classpath, so I had to add:

task copyTestResources(type: Copy) {
    from "${projectDir}/src/test/resources"
    into "${buildDir}/classes/test"
}
processTestResources.dependsOn copyTestResources
task copyMainResources(type: Copy) {
    from "${projectDir}/src/main/resources"
    into "${buildDir}/classes/main"
}
copyTestResources.dependsOn copyMainResources

Hope this is fixed soon... "

I can also confirm this as still an issue in 2.2

Thank you Goncalos, I spent so long trying to work out why the classloader wasn't picking up my resources (main not test). On the plus side you could say I know a bit more about classloader now.

$ jps -mv | grep studio
37605 -Dfile.encoding=UTF-8 -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Djna.nosys=true ...