[TIMOB-28089] Android: Local aar files are not handled well
| GitHub Issue | n/a |
|---|---|
| Type | Improvement |
| Priority | None |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | Release 9.0.3 |
| Fix Version/s | n/a |
| Components | n/a |
| Labels | n/a |
| Reporter | Hans Knöchel |
| Assignee | Unknown |
| Created | 2020-08-19T11:31:48.000+0000 |
| Updated | 2021-01-30T18:38:51.000+0000 |
Description
Local aar files used to work great in Titanium until SDK 9, where we could not place them into the "lib" directory anymore. Thanks to @m1ga, there is a workaround, where we can copy it to "libs" and compile the module fine afterwards.
Unfortunately, during app build, the aar file is not found again, which can be fixed by using a precompile hook like [this one](https://github.com/AppWerft/Ti.Infonline/blob/95481db5dee9f11bab556fe012492532d08aa255/android/hooks/copy_libs.js) + a super hacky local directory where the aar can be placed.
Obviously, this is not great, so the Titanium CLI should watch out for aar files under /libs and handle them properly. Hacks like extracting the jar and using that are not productive and won't work in cases like ours, where the aar also has resources like config files.
First, I need to say Google's build system does *+NOT+* support this for library projects. While you can set up an Android library project to "link" against a local AAR, it will *+NOT+* "merge" the AAR into the built library. Only an Android app project will "merge" a local AAR. Again, this is how Google made it and you can confirm this in Android Studio. Meaning what you want requires a "hack" to make this work for a native Android Studio developer. And if it requires a "hack" to make it work natively in Android Studio, it means it requires a "hack" to make it work in Titanium's build system too. Also, we want to encourage developer to use the gradle dependency management system over local AARs, because it avoids "class name collision" build failures which plagued us before. This means less tech-support issues for us. Since the vast majority of AARs people need can be referenced this way, I'm okay with keeping it this way (just like how Google is okay with keeping it this way).
I cannot agree on that. First, I'm sad to see this being edited as a "Improvement" instead of a "Bug". Things that worked before and also work on native Android projects but don't in Titanium rather feels like bugs to me. Regarding the issue: We simply don't live in that perfect world of deployed libraries that are managed through maven/google. Especially in the B2B area, I've seen so many libraries that are distributed via an aar file and other frameworks / native Android seems to be fine with it. In addition, their sample projects are simple: Just reference the aar like we do in our workaround and it's fine. The only thing is that the build "pipeline" does not pick up those files and that causes people to go for (temporary) hacks before looking for alternate frameworks over the long term.
Are there any workarounds for this? Some software vendors simply do not distribute their libraries via Gradle (like AWS for some of it's libs), so these have to be handled somehow. In native Android, this is done by placing them into the "app/libs" directory, but this does not seem to work in Titanium.