Linting fails when importing AAR file with implemenation files [322437895]

Fixed

Bug

Status Update

No update yet.

Description

an...@nrk.no

created issue #1

Jan 26, 2024 06:36PM

Describe the bug or issue that you're seeing.

We have a project with multiple modules using apply plugin: 'com.android.library'. One of these modules (called analytics) needs to use an external AAR file. We have tried to set it up as described here. This seems to build just fine when for instance building a regular APK, but linting fails.

For instance when we run lintDebug we get this error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':analytics:bundleDebugLocalLintAar'.
> Error while evaluating property 'hasLocalAarDeps' of task ':analytics:bundleDebugLocalLintAar'.
   > Direct local .aar file dependencies are not supported when building an AAR. The resulting AAR would be broken because the classes and Android resources from any local .aar file dependencies would not be packaged in the resulting AAR. Previous versions of the Android Gradle Plugin produce broken AARs in this case too (despite not throwing this error). The following direct local .aar file dependencies of the :analytics project caused this error: [here there is the path to the .aar file]

We don't need the modules to be built as AAR-files, in the end they'll just be part of the final app. But then we assume there's either something missing in the documentation, there is an error with the linting or that we are missing some setup.

A similar issue has been discussed on StackOverflow, but that's for modules that are going to be used as actual libraries in the end - and they are refering to an old method that I guess aren't recommended anymore?

Attach log files from Android Studio

As this most likely isn't an issue with Android Studio (I just weren't allowed to create the issue anywhere else) I don't think this is needed - but let me know if it is!

If you know what they are, write the steps to reproduce:

Create new Android project
Add extra module and add implementation files(...) with an AAR-file
Run the lintDebug task or something alike it

Additional information

Build: AI-231.9392.1.2311.11330709, 202401190053

AI-231.9392.1.2311.11330709, JRE 17.0.7+0-b2043.56-10550314x64 JetBrains s.r.o., OS Windows 10(amd64) v10.0 , screens 9600.0x6000.0

AS: Hedgehog | 2023.1.1 Patch 2
Kotlin plugin: 231-1.9.22-release-704-AS9392.1.2311.11330709
Android Gradle Plugin: 8.2.2
Gradle: 8.2
Gradle JDK: JetBrains Runtime version 17.0.7
NDK: from local.properties: (not specified), latest from SDK: (not found)
CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)

Comments

kd...@google.com <kd...@google.com> Jan 26, 2024 09:59PM

Assigned to an...@google.com.

pa...@google.com <pa...@google.com> Jan 30, 2024 01:00PM

Status: New

an...@nrk.no <an...@nrk.no> #2Oct 1, 2024 10:37AM

I am not sure I understand the use case. how can the benchmark be code to real world scenario when it's not possible to do right now ? which scenario is it ?

In any case, since this would be for benchmarking, this would clearly not be available through the public DSL. We should find a semi-private way of doing this (maybe the private variant API object could offer that functionality for instance or a property).

pa...@google.com <pa...@google.com> #3Oct 1, 2024 11:46AM

Assigned to an...@google.com.

We want benchmarks to measure code after Progaurd / R8, but it's not possible to turn that on for androidTests in library modules at the moment (to my knowledge?)

Benchmarks are also a public facing thing, but we have a plugin to help configure gradle builds for our users, so if support for this ends up in a private API, we could try to keep those usages localized to our code perhaps.

sp...@google.com <sp...@google.com> Oct 1, 2024 06:36PM

Reassigned to sp...@google.com.

sp...@google.com <sp...@google.com> #4Oct 2, 2024 03:04AM

Marked as fixed.

Hi Jerome,

Any update on the status of this request and when it can be supported?

Thanks,
Amanda

an...@nrk.no <an...@nrk.no> #5Oct 2, 2024 07:21AM

this is not part of our OKR at this point so we are not talking soon. at first glance, we would need to simulate usage patterns to minify against and such, this seems substantial amount of work. there are not a lot of library module that have android tests, most only rely on unit-tests.

how important is this ? we are out of PM right now but I suspect the next step will be to negotiate with J. Eason and xav@ to scale a priority level.

an...@google.com <an...@google.com> #6Oct 3, 2024 07:49PM

This is a high priority request for Compose, to enable their benchmarks to measure release accurate performance. (Micro) Benchmarks are library modules, as they don't need the complexity of multi-apk tests - they're self measuring APKs that depend on libraries. (d.android.com/benchmark)

there are not a lot of library module that have android tests, most only rely on unit-tests.

To clarify, this is for com.android.library modules, not jars - I'd expect most of those to use android tests (all of the libraries in jetpack for example do).

we would need to simulate usage patterns to minify against and such, this seems substantial amount of work

Simulate usage patterns? I don't understand - the dev can themselves provide a keep rule for test infra / classes if necessary. Long term, keep rules should be provided by test libraries.