[jnigen] unable to resolve dependencies for a Android library (aar)

[abhaysood]

I'm trying to use jnigen with an AAR (Android Archive). But seems like jnigen looks for a JAR file specifically.

[ERROR] dependency: sh.measure:measure-android:jar:0.9.0 (compile)
[ERROR]	Could not find artifact sh.measure:measure-android:jar:0.9.0 in central (https://repo1.maven.org/maven2)
[ERROR]	Could not transfer artifact sh.measure:measure-android:jar:0.9.0 from/to github (https://maven.pkg.github.com/measure-sh/measure): status code: 401, reason phrase: Unauthorized (401)
[ERROR]	Could not find artifact sh.measure:measure-android:jar:0.9.0 in google-maven-repo (https://maven.google.com)

You can see that the AAR is present at the maven central, however jnigen fails as it was expecting to find a JAR instead of an AAR. Will AARs be supported with jnigen, or please guide if I am configuring this incorrectly.

For more context, this is the jnigen.yaml I'm using:

output:
  dart:
    path: lib/src/jni_bridge.dart
    structure: single_file

classes:
  - 'sh.measure.android.events.SignalProcessorImpl'

maven_downloads:
  source_deps:
    - 'sh.measure:measure-android:0.9.0'

[abhaysood]

I am guessing the same applies here, closing this issue. This can be achieved by providing class paths to jnigen using a custom script.

The maven support in jnigen.yaml was added for convenience but I always planned to eventually remove it. I suggest writing your maven config in the way that its intended in pom.xml and create a script that will download from maven and run jnigen. You can pass source and class paths to jnigen.yaml.

https://github.com/dart-lang/native/issues/1971#issuecomment-2637478416

[Gustl22]

@HosseinYousefi Would it be possible to have a forward example which involves using aars (e.g. in one of the example projects)? Thank you for the infos.

[HosseinYousefi]

The explicit support for AARs could be added. This is different to the maven issue because AAR is an archive format similar to JAR that can be read.

[jwill]

Short term workaround:

1. Clone the dart-lange/native repo
2. Update your jni/jnigen to reference the path (changes have landed in main but haven't been published yet).
3. Run jni:setup, jnigen:setup and dart run jnigen --config jnigen.yaml as normal. That will get you the source code. The next to last step of dart run jnigen --config jnigen.yaml will fail at this point and complain about resolution problems (see longer explaination).
4. Download the aar files you need, extract them and place their classes.jar files into your maven_downloads: >> jar_dir directory (default mvn_jar)
5. Re-run dart run jnigen --config jnigen.yaml [you will still get errors because the second gradle build technically errors out but the codegen will complete)
6. Profit.

Longer explanation

So as of 0.14.1, the errors are a bit different. I landed changes to jni and jnigen to move the maven bits over to all Gradle. Gradle as you know is more Android friendly so we get more descriptive errors thanks to Gradle's dependency resolution.

What fails is when Gradle tries to find the compiled sources, because it finds an aar and tries to find an appropriate build library for the platform and variant. (Error excerpt and image are the same error, image just has better highlighting)

` > Could not resolve all files for configuration ':runtimeClasspath'.

Could not resolve sh.measure:measure-android:0.9.0. Required by: project : > No matching variant of sh.measure:measure-android:0.9.0 was found. The consumer was configured to find a library for use during runtime, compatible with Java 11, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but: - Variant 'releaseVariantReleaseApiPublication' declares a library, and its dependencies declared externally: - Incompatible because this component declares a component for use during compile-time, with the library elements 'aar' and the consumer needed a component for use during runtime, packaged as a jar - Other compatible attributes: - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs) - Doesn't say anything about its target Java version (required compatibility with Java 11) `

The good news is that you can currently easily work around this, download your required aar file, extract it and place its bundled classes.jar into maven_downloads: >> jar_dir which defaults to mvn_jar and then re-run dart run jnigen --config jnigen.yaml

The likely long term fix is probably to tweaking the variant of the stub build.gradle.kts/doing a second pass with tweaked variant or append to the android_sdk_tools.

[HosseinYousefi]

You can see that the AAR is present at the maven central, however jnigen fails as it was expecting to find a JAR instead of an AAR. Will AARs be supported with jnigen, or please guide if I am configuring this incorrectly.

I just opened the link and there also is a source jar.

So as of 0.14.1-wip

Just published 0.14.1.

The good news is that you can currently easily work around this

Downloading and extracting it also always works. The path can be added to source_path when it's source and class_path when it's bytecode.

[jwill]

Right, that was existing behavior (grabbing of *-sources.jar), updated my comment.

~~Note for later @jwill or @HosseinYousefi , untested hypothesis is that org.gradle.jvm.environment in gradle.properties of the stub gradle build being set to android versus the default standard-jvm might allow grabbing the aar "automatically." Albeit some post processing extraction will still be needed.~~

~~https://docs.gradle.org/8.7/userguide/variant_attributes.html#sub:jvm_default_attributes~~

I'm back to feeling one should use android_sdk_config settings versus wanting to download them in the maven_downloads section

[HosseinYousefi]

@abhaysood If you use the jnigen on the main branch, do you still hit this issue? We're now using gradle instead of maven to download things and as I mentioned in my previous comment, at least the library you provided does indeed have a -sources.jar version available so the issue should not be related to the lack of .arr support.

That said, I can add the support for APISummarizer to also support reading .arr files – it's not much work as each .arr file has a classes.jar file within it.

@jwill Since you have worked on the maven downloads parts and changed it to use gradle, could you please replace some of the logic to also be fine with .arr as well as .jars?