React-native-notifee: Execution failed for task ':notifee_react-native:bundleReleaseAar'.

[khlling]

Hi,

I've just purchased a license for Notifee and have been integrating within my app. So far so good, the documentation is clear enough to get going and I've got the integration with Firebase/FCM working for the Android emulator so thanks for the hard work so far!

However I'm having trouble assembling for testing on a physical device: ./gradlew assembleRelease with the exception error

Execution failed for task ':notifee_react-native:bundleReleaseAar'.
> 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 :notifee_react-native project caused this error: ***/node_modules/@notifee/react-native/android/libs/notifee_core_release.aar

I'm assuming that this is to do with my upgrade of gradle version

Gradle 6.1.1
------------------------------------------------------------

Build time:   2020-01-24 22:30:24 UTC
Revision:     a8c3750babb99d1894378073499d6716a1a1fa5d

Kotlin:       1.3.61
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          1.8.0_242 (AdoptOpenJDK 25.242-b08)
OS:           Mac OS X 10.15.4 x86_64

As the only reference I've found elsewhere to this issue is here

I'm not very familiar with gradle management but I'm assuming directly referencing the .aar file probably only a temporary fix?

[mikehardy]

I believe the temporary fix is to not update - quite yet - to Android Studio 4 - it just released about 36 hours ago I think, so waiting a bit more should be fine. I am assuming you have updated yes?

There was a related build break in react-native-firebase, in general this release has a few side effects that the ecosystem needs time to deal with

[mikehardy]

@Salakar / @Ehesp this is a hot one even with my advice to not use Android Studio 4 temporarily, obviously that's not viable even short term - this will get everyone if my diagnosis of the proximal cause is correct (I haven't attempted to reproduce yet)

[Ehesp]

Interesting! We haven't actually updated yet (always scared of trying EAPs) but we'll get this checked-out ASAP.

[khlling]

@mikehardy That's correct, I updated without really thinking about it as it's been a while since I've opened Android Studio. I did notice in the Google developer updates that Android Studio 4 had just come out but didn't put 2 and 2 together doh! 🙄

@Ehesp Much appreciated. I don't know if this will affect Notifee but there's conflict in guava implementation for listeanablefuture so I had to add:

implementation 'com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava'

Not sure if that's a by product of the update. Source:
https://mvnrepository.com/artifact/com.google.guava/listenablefuture

[mikehardy]

Interesting extra point there thanks for mentioning that @khlling - Android Studio added a bunch more Java 8 de-sugaring as well so that's the likely culprit there. Not often your IDE has a major revision / breaking change release, this one has a few new sharp corners on it to handle as module maintainers...

[khlling]

Happy to help, a stable and feature rich notifications module for react native would definitely be a positive contribution to the ecosystem.

Yeah the changes are pretty low level but quite wide reaching, hopefully updates will filter through rapidly.

[khlling]

@Ehesp Any progress on this?

For those who are interested, as a workaround I've downgraded my Android Studio version to v3.6.3

I also had to reset my gradle versions:

android/gradle/wrapper/gradle-wrapper.properties

distributionUrl=https\://services.gradle.org/distributions/gradle-5.6.4-all.zip

/android/build.gradle

classpath('com.android.tools.build:gradle:3.6.2')

I still get this warning:

> Task :notifee_react-native:bundleReleaseAar
WARNING: The AAR produced by this build for the :notifee_react-native project is broken. Direct local .aar file dependencies are not supported when building an AAR. The resulting AAR is broken because the classes and Android resources from any local .aar file dependencies are not packaged in the resulting AAR. Previous versions of the Android Gradle Plugin produce broken AARs in this case too (despite not having this warning), and this warning will be replaced with an error in subsequent versions of the Android Gradle Plugin. The following direct local .aar file dependencies caused this warning: /***/node_modules/@notifee/react-native/android/libs/notifee_core_release.aar

Which seems serious but running ./gradlew assembleRelease successfully completes and I've tested notifications on my device and it work as expected.

[bjjeong]

Any updates on this?

[mikehardy]

I cannot reproduce with gradle 6.6, gradle plugin 4.0.1, notifee current (12.1 I believe) - notifee in my work project is buliding and works fine

[bjjeong]

I'm currently failing to build with gradle 6.5.1, gradle plugin 4.0.1, and notifee 0.12.1. Will report back after trying with gradle 6.6.

[bjjeong]

Interestingly, the build fails when I run ./gradlew assembleRelease but not when I manaully generate a signed bundle/APK through Android Studio.

[mikehardy]

Yeah, 4.0.1. That is most strange. Perhaps there are different JDKs or gradles in use via different environment settings (JAVA_HOME, ANDROID_HOME) in your configuration? I am not saying there is not a problem but your reproduction report naturally makes me lean heavily towards "this is a project-specific problem" vs "we have a bug in the module". Which doesn't change your situation but is a relief as this shouldn't be blocking others at least.

Android Studio should show you exactly what it is doing, a comparison between command line environment and Android Studio should show the difference?

[bjjeong]

Got it to build - looks like I had to run gradlew app:assembleRelease instead of just gradlew assembleRelease.

[mikehardy]

Very happy to see you've got one success path - I can still say my project works correctly without the :app: prefix so I think you might still have something worth investigating at the project level, but (as a native Android developer also) there is nothing wrong with using that prefix at a gradle level and if it works, it works!

[bjjeong]

@mikehardy I appreciate the help Mike! I'll have to investigate further