Alright, so really just posting as a sanity check, and making sure I'm not doing my android all wrong. Essentially, it seems needing to use multiDexEnabled true is not best practice, as it means the app is getting "big", aka bloated. But it takes very little to get there with the tools I'm using, which I'll outline below.
TL;DR: Using multidex seems to be bad practice, is there a different solution?
Starting with a vanilla Ignite CLI Bowser project, a template engine for React Native, and adding the React Native Facebook SDK according to the official guide, results in a build error for the android application.
ignite new TestApp
cd TestApp && yarn add react-native-fbsdk && npx react-native link react-native-fbsdk
Following Android Guide, make relevant changes to
TestApp/android/app/src/main/java/com/testapp/MainApplication.java and TestApp/android/settings.gradle
Then, following the linked Facebook SDK guide (auth wall), made the relevant changes to TestApp/android/app/build.gradle, TestApp/android/app/src/main/res/values/strings.xml and TestApp/android/app/src/main/AndroidManifest.xml
Then, running npx react-native run-android, results in the following build error:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:mergeDexDebug'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
> com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives:
The number of method references in a .dex file cannot exceed 64K.
Learn how to resolve this issue at https://developer.android.com/tools/building/multidex.html
More searches point to a fix of adding multiDexEnabled true to defaultConfig within the module build.gradle, which does fix the error. The issue, is most of those solutions also lead to others pointing out poor library management, importing too much, etc.
So, am I doing something wrong, or is this just the result of using Facebook SDK and Ignite CLI and there's nothing I can do about it? I just worry, as I was hoping to add more than one provider's OAuth to the application, but don't want a bloated application that never loads.
It's not related to libraries used in your project but to the number of methods used.
When your app and the libraries it references exceed 65,536 methods, you encounter a build error that indicates your app has reached the limit of the Android build architecture and you have to turn on multidex to be able to support more methods.
https://developer.android.com/studio/build/multidex
Related
(using android,
openjdk-11.0.13_8
node v16.13.2
react-native 0.67.0)
i created a barebone react-native project with
npx react-native init testapp
then signed it according to official react-native documentation
then tried to create the release-variant with npx react-native run-android --variant=release
now i get BUILD SUCCESSFUL message and got apk, and it installs and works in my physical device...
BUT, i got a lot of gradle problem-warning ...here is one sample..
Task :app:processReleaseManifestForPackage Execution optimizations have been disabled for task ':app:processReleaseManifestForPackage' to
ensure correctness due to the following reasons:
Gradle detected a problem with the following location: 'D:\testapp\android\app\build\intermediates\merged_manifests\release'.
Reason: Task ':app:processReleaseManifestForPackage' uses this output
of task ':app:copyReleaseBundledJs' without declaring an explicit or
implicit dependency. This can lead to incorrect results being
produced, depending on what order the tasks are executed. Please refer
to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.
this same problem-warning is repeated for many other tasks!!...
NB i havent added any packages or changed any source code.. its the barebone app coming with react-native!... so how do i solve this issue?.. how to fix my settings so that this warning can be removed...
(i copied one of these tasks-names and did a text-search inside all files in my project directory to find out where its mentioned...but shockingly, its not mentioned anywhere!!!...so where are all these problem-warnings coming from? and how can we get a neat gradle build?)
this same warning is repeated in lots of lines in gradle output for other tasks too, such as:
Task :app:compressReleaseAssets
Task :app:processReleaseManifestForPackage
etc.. etc..
I'm trying to open and run the android architecture components sample project here: https://github.com/android/architecture-components-samples/tree/main/GithubBrowserSample in Android Studio. One one machine I'm able to get the project built and run just fine, but on my primary machine I'm seeing a build task error:
A problem was found with the configuration of task ':app:generateSafeArgsDebug' (type 'ArgumentsGenerationTask').
> No value has been specified for property 'enableGradleWorkers'.
I've tried the version of gradle and the gradle plugin that the project seems to have been built with, as well as the latest of each. I do have "android.enableGradleWorkers=true" specified in gradle.properties.
I haven't found this message when searching around, but I often see similar-looking errors when opening projects from different sources. I'd love to be able to fix this one, and ideally understand more about what to check when encountering build errors with projects from different sources in the future.
Using Android Room with Kapt on MacOS Catalina, I get the following errors building the project. The project builds successfully if I remove kapt "androidx.room:room-compiler:$room_version" from my build.gradle.
Failed to load native library:sqlite-3.25.2-60e239c7-424b-4b75-bfd5-b2df4aa8e01a-libsqlitejdbc.jnilib. osinfo: Mac/x86_64
java.lang.UnsatisfiedLinkError: $TMPDIR/sqlite-3.25.2-60e239c7-424b-4b75-bfd5-b2df4aa8e01a-libsqlitejdbc.jnilib: dlopen($TMPDIR/sqlite-3.25.2-60e239c7-424b-4b75-bfd5-b2df4aa8e01a-libsqlitejdbc.jnilib, 1): no suitable image found. Did find:
$TMPDIR/sqlite-3.25.2-60e239c7-424b-4b75-bfd5-b2df4aa8e01a-libsqlitejdbc.jnilib: code signature in ($TMPDIR/sqlite-3.25.2-60e239c7-424b-4b75-bfd5-b2df4aa8e01a-libsqlitejdbc.jnilib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
Failed to load native library:sqlite-3.25.2-79b61bc4-bdd0-4451-a523-5baa49728398-libsqlitejdbc.jnilib. osinfo: Mac/x86_64
java.lang.UnsatisfiedLinkError: $TMPDIR/sqlite-3.25.2-79b61bc4-bdd0-4451-a523-5baa49728398-libsqlitejdbc.jnilib: dlopen($TMPDIR/sqlite-3.25.2-79b61bc4-bdd0-4451-a523-5baa49728398-libsqlitejdbc.jnilib, 1): no suitable image found. Did find:
$TMPDIR/sqlite-3.25.2-79b61bc4-bdd0-4451-a523-5baa49728398-libsqlitejdbc.jnilib: code signature in ($TMPDIR/sqlite-3.25.2-79b61bc4-bdd0-4451-a523-5baa49728398-libsqlitejdbc.jnilib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
Which produces the following exception
Caused by: java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8([BI)V
at org.sqlite.core.NativeDB._open_utf8(Native Method)
at org.sqlite.core.NativeDB._open(NativeDB.java:78)
at org.sqlite.core.DB.open(DB.java:195)
at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:243)
at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:61)
at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:21)
at org.sqlite.JDBC.createConnection(JDBC.java:116)
at androidx.room.verifier.DatabaseVerifier$Companion.create(DatabaseVerifier.kt:104)
at androidx.room.processor.DatabaseProcessor.doProcess(DatabaseProcessor.kt:82)
at androidx.room.processor.DatabaseProcessor.process(DatabaseProcessor.kt:57)
at androidx.room.RoomProcessor$DatabaseProcessingStep.process(RoomProcessor.kt:134)
at com.google.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:330)
at com.google.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:181)
at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt)
at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:147)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:985)
... 39 more
It looks like this is different from https://github.com/xerial/sqlite-jdbc/issues/97, which is the only issue I could find any information about. Is there any way to work around this issue?
Edit:
I ended up finding this blog post, which led me to this JDK issue. I verified that ./gradlew :app:kaptDebugKotlin worked with my JDK11, and updated IDEA to use that JDK as it's runtime, as well as telling it to execute builds with gradle instead of IDEA. Neither of those seemed to fix the issue - running ./gradlew clean :app:kaptDebugKotlin in my terminal with JDK11 succeeded, but running that gradle task through IDEA failed.
I ended up working around it by removing gradle-aware make from my run configuration, and running ./gradlew :app:assembleDebug every time I make changes to the app. It's a little annoying and adds an extra step, but I can still run/update the app.
Figured it out - it turns out the Gradle setting for Java SDK is ignored in Android projects, and instead the Java SDK from the Android SDK is used for gradle tasks. Setting the Android SDK's Java SDK to JDK11 fixed the issue, because that JDK has the fix for JDK-8223671
I'm using Android Studio with NDK, Gradle and CMake to build several shared libraries and link them together.
I keep getting the same error again and again in the build log:
:app:processDebugManifest [Passed]
:app:externalNativeBuildDebug [Passed]
Source C:\XXX\app\build\intermediates\cmake\debug\obj\arm64-v8a\libBGS-d.so and destination C:\XXX\app\build\intermediates\cmake\debug\obj\arm64-v8a\libBGS-d.so must be different
It's like gradle is trying to copy my library at the same position.
The thing is, I have no idea where this instruction comes from and how I can debug it. There's really not much indication in the build log.
What's confusing is that is doesn't occur 100% of the time. Seems like there is a race condition somewhere. Also sometimes it's another library that triggers the build to fail. Also, cleaning the project doesn't help.
So here's my question: is there any place where I can get granular control over the Gradle build sequence ?
According to Dan Albert at https://stackoverflow.com/a/62223434/8068814 this appears to be a bug and he suggests cleaning the project, then triggering "refresh linked c++ projects" and then building the project. Since it is sometimes working for you, this might be a reliable solution in your case.
For me this did not help, but reverting the Gradle plugin to 3.6.2 was the only way for me to build my project.
I have a ReactNative application and have no experience in android development.
Currently, I have a problem with integrating detox with my app (app compiles and works fine if just run it through react-native run-android).
I found quite a lot of similar questions, where the general advice just setting "multiDexEnabled true" in the build.gradle file, which does not work in my case.
Another advice is the "three reshaking" for dependencies, but trying that with lack of experience brought other build errors.
So Android-masters, could you share your methods about how to fix the subject in android build process?
[UPD1] The issue appears only when I try to build app for detox using detox build -c android.emu.debug
Task :tipsi-stripe:mergeDexDebugAndroidTest FAILED
java.lang.RuntimeException: java.lang.RuntimeException: com.android.builder.dexing.DexArchiveMergerException: Error while merg
ing dex archives:
The number of method references in a .dex file cannot exceed 64K.
...
App builds and works fine for debug/release configurations.
It fails by handling tipsi-stripe package, which led me to https://github.com/tipsi/tipsi-stripe/issues/273
where nenti suggests sort of three reshaking, as I understood.
But that did not help (probably due to I have different package versions)
So my question how to do repeat that advice with my packages versions.
Make sure you're adding the "multiDexEnabled true" config to the build.gradle of the tipsi-stripe node module.
That isn't a permanent fix however.
Github issue in tipsi-stripe for reference: https://github.com/tipsi/tipsi-stripe/issues/569