Revert "Bug 1823532 - Remove jnaForTest from project Gradle build files."

This reverts commit 92c1b9e.

Author: csadilek

android-components/build.gradle

@@ -228,6 +228,28 @@ subprojects {
                 }
             }
 
+            configurations {
+                // There's an interaction between Gradle's resolution of dependencies with different types
+                // (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
+                // JUnit test runner.  The runtime classpath in the built-in JUnit test runner gets the
+                // dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
+                // doesn't provide the JNI dispatch libraries in the correct Java resource directories.  I think
+                // what's happening is that @aar type in `implementation` resolves to the @jar type in
+                // `testImplementation`, and that it wins the dependency resolution battle.
+                //
+                // A workaround is to add a new configuration which depends on the @jar type and to reference
+                // the underlying JAR file directly in `testImplementation`.  This JAR file doesn't resolve to
+                // the @aar type in `implementation`.  This works when invoked via `gradle`, but also sets the
+                // correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
+                // Success!
+                jnaForTest
+            }
+
+            dependencies {
+                jnaForTest ComponentsDependencies.thirdparty_jna
+                testImplementation files(configurations.jnaForTest.copyRecursive().files)
+            }
+
             if (project.hasProperty("coverage") && project.name != "support-test") {
                 android.buildTypes.all { buildType ->
                     tasks.withType(Test).configureEach() {

android-components/components/service/glean/build.gradle

@@ -23,6 +23,23 @@ android {
     namespace 'mozilla.components.service.glean'
 }
 
+configurations {
+    // There's an interaction between Gradle's resolution of dependencies with different types
+    // (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
+    // JUnit test runner.  The runtime classpath in the built-in JUnit test runner gets the
+    // dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
+    // doesn't provide the JNI dispatch libraries in the correct Java resource directories.  I think
+    // what's happening is that @aar type in `implementation` resolves to the @jar type in
+    // `testImplementation`, and that it wins the dependency resolution battle.
+    //
+    // A workaround is to add a new configuration which depends on the @jar type and to reference
+    // the underlying JAR file directly in `testImplementation`.  This JAR file doesn't resolve to
+    // the @aar type in `implementation`.  This works when invoked via `gradle`, but also sets the
+    // correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
+    // Success!
+    jnaForTest
+}
+
 // Define library names and version constants.
 String GLEAN_LIBRARY = "org.mozilla.telemetry:glean:${Versions.mozilla_glean}"
 String GLEAN_LIBRARY_FORUNITTESTS = "org.mozilla.telemetry:glean-native-forUnitTests:${Versions.mozilla_glean}"

android-components/plugins/dependencies/src/main/java/DependenciesPlugin.kt

@@ -39,6 +39,7 @@ object Versions {
     // zxing 3.4+ requires a minimum API of 24 or higher
     const val zxing = "3.3.3"
 
+    const val jna = "5.13.0"
     const val disklrucache = "2.0.2"
     const val leakcanary = "2.10"
 
@@ -196,6 +197,7 @@ object ComponentsDependencies {
     const val thirdparty_okhttp_urlconnection = "com.squareup.okhttp3:okhttp-urlconnection:${Versions.okhttp}"
     const val thirdparty_sentry_latest = "io.sentry:sentry-android:${Versions.sentry_latest}"
     const val thirdparty_zxing = "com.google.zxing:core:${Versions.zxing}"
+    const val thirdparty_jna = "net.java.dev.jna:jna:${Versions.jna}@jar"
     const val thirdparty_disklrucache = "com.jakewharton:disklrucache:${Versions.disklrucache}"
 
     const val firebase_messaging = "com.google.firebase:firebase-messaging:${Versions.Firebase.messaging}"

fenix/app/build.gradle

@@ -470,6 +470,23 @@ nimbus {
     experimenterManifest = ".experimenter.yaml"
 }
 
+configurations {
+    // There's an interaction between Gradle's resolution of dependencies with different types
+    // (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
+    // JUnit test runner.  The runtime classpath in the built-in JUnit test runner gets the
+    // dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
+    // doesn't provide the JNI dispatch libraries in the correct Java resource directories.  I think
+    // what's happening is that @aar type in `implementation` resolves to the @jar type in
+    // `testImplementation`, and that it wins the dependency resolution battle.
+    //
+    // A workaround is to add a new configuration which depends on the @jar type and to reference
+    // the underlying JAR file directly in `testImplementation`.  This JAR file doesn't resolve to
+    // the @aar type in `implementation`.  This works when invoked via `gradle`, but also sets the
+    // correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
+    // Success!
+    jnaForTest
+}
+
 tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach {
     kotlinOptions {
         freeCompilerArgs += [
@@ -480,6 +497,9 @@ tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach {
 }
 
 dependencies {
+    jnaForTest FenixDependencies.jna
+    testImplementation files(configurations.jnaForTest.copyRecursive().files)
+
     implementation project(':browser-engine-gecko')
 
     implementation FenixDependencies.kotlin_coroutines

fenix/buildSrc/src/main/java/FenixDependencies.kt

@@ -18,6 +18,7 @@ object FenixVersions {
     const val leakcanary = "2.10"
     const val osslicenses_plugin = "0.10.4"
     const val detekt = "1.19.0"
+    const val jna = "5.13.0"
 
     const val androidx_activity = "1.6.1"
     const val androidx_compose = "1.3.1"
@@ -120,6 +121,8 @@ object FenixDependencies {
     const val adjust = "com.adjust.sdk:adjust-android:${FenixVersions.adjust}"
     const val installreferrer = "com.android.installreferrer:installreferrer:${FenixVersions.installreferrer}"
 
+    const val jna = "net.java.dev.jna:jna:${FenixVersions.jna}@jar"
+
     const val junit = "junit:junit:${FenixVersions.junit}"
     const val mockk = "io.mockk:mockk:${FenixVersions.mockk}"
     const val mockk_android = "io.mockk:mockk-android:${FenixVersions.mockk}"

focus-android/app/build.gradle

@@ -207,6 +207,23 @@ nimbus {
     experimenterManifest = ".experimenter.yaml"
 }
 
+configurations {
+    // There's an interaction between Gradle's resolution of dependencies with different types
+    // (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
+    // JUnit test runner.  The runtime classpath in the built-in JUnit test runner gets the
+    // dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
+    // doesn't provide the JNI dispatch libraries in the correct Java resource directories.  I think
+    // what's happening is that @aar type in `implementation` resolves to the @jar type in
+    // `testImplementation`, and that it wins the dependency resolution battle.
+    //
+    // A workaround is to add a new configuration which depends on the @jar type and to reference
+    // the underlying JAR file directly in `testImplementation`.  This JAR file doesn't resolve to
+    // the @aar type in `implementation`.  This works when invoked via `gradle`, but also sets the
+    // correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
+    // Success!
+    jnaForTest
+}
+
 dependencies {
     implementation FocusDependencies.androidx_appcompat
     implementation FocusDependencies.androidx_browser
@@ -304,6 +321,8 @@ dependencies {
     focusImplementation FocusDependencies.adjust
     focusImplementation FocusDependencies.install_referrer // Required by Adjust
 
+    jnaForTest FocusDependencies.jna
+    testImplementation files(configurations.jnaForTest.copyRecursive().files)
     testImplementation "org.mozilla.telemetry:glean-native-forUnitTests:${project.ext.glean_version}"
 
     testImplementation FocusDependencies.testing_junit_api

focus-android/buildSrc/src/main/java/FocusDependencies.kt

@@ -63,6 +63,7 @@ object FocusVersions {
     }
 
     object ThirdParty {
+        const val jna = "5.13.0"
         const val leakcanary = "2.10"
         const val osslicenses_plugin = "0.10.4"
         const val sentry = "6.15.0"
@@ -110,6 +111,7 @@ object FocusDependencies {
     const val google_play = "com.google.android.play:core:${FocusVersions.Google.play}"
     const val kotlin_gradle_plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:${FocusVersions.Gradle.kotlin_plugin}"
     const val android_gradle_plugin = "com.android.tools.build:gradle:${FocusVersions.Gradle.android_plugin}"
+    const val jna = "net.java.dev.jna:jna:${FocusVersions.ThirdParty.jna}@jar"
     const val leakcanary = "com.squareup.leakcanary:leakcanary-android-core:${FocusVersions.ThirdParty.leakcanary}"
     const val sentry = "io.sentry:sentry-android:${FocusVersions.ThirdParty.sentry}"