When will AndroidX be available as a NuGet?
AlexanderMelchers opened this issue · comments
Xamarin.Android Version:
9.1.7.0
Operating System & Version:
Windows 10 Pro, version 1809 (OS Build 17763.316)
Support Libraries Version:
28.0.0.1
Describe your Issue:
One of our partners has recently switched their native SDK, which we use in our App, from using the old Android Support libraries to using AndroidX. When POC-testing whether the newest version of their SDK works correctly, we now run into the following exception: java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/core/app/ActivityCompat; Caused by: java.lang.ClassNotFoundException: Didn't find class "androidx.core.app.ActivityCompat" on path: DexPathList. This is what lead me to your Github.
Yet, now my question is when the AndroidX-libraries will be available for use as a NuGet. Is there a timeline? And will it be possible to install this NuGet in addition to the existing Android Support libraries, or will the two be mutually exclusive? Also - though this is probably not the right place to ask - is there another way we could skip ahead and already include AndroidX in our project, seeing as that we don't need any public bindings, just need the library for support of our SDK?
Steps to Reproduce:
We've created a binding library of our partner's proprietary SDK. After updating the JAR-file in this library to one that uses AndroidX support libraries, our POC-project crashes when the SDK tries to bring up a permission request dialog. As the SDK is proprietary, I can unfortunately not supply it here. This, moreover, defeats providing the binding library (which is otherwise empty) and therefore POC-project.
Include any relevant Exception Stack traces, build logs, adb logs:
Below is a full stack trace of the exception that is thrown with respect to the missing AndroidX library, obfuscated with respect to the name of our partner company.
02-27 11:48:49.947 E/AndroidRuntime(24752): FATAL EXCEPTION: sdk-worker
02-27 11:48:49.947 E/AndroidRuntime(24752): Process: POC.Android, PID: 24752
02-27 11:48:49.947 E/AndroidRuntime(24752): java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/core/app/ActivityCompat;
02-27 11:48:49.947 E/AndroidRuntime(24752): at com.partner.sdk.PermissionRequest.permissionsGranted(PermissionRequest.java:46)
02-27 11:48:49.947 E/AndroidRuntime(24752): at com.partner.sdk.PermissionRequest.request(PermissionRequest.java:53)
02-27 11:48:49.947 E/AndroidRuntime(24752): at com.partner.sdk.library.Sdk$StartRunnable$1.run(Sdk.java:183)Thread started: #2
02-27 11:48:49.947 E/AndroidRuntime(24752): at android.os.Handler.handleCallback(Handler.java:789)
02-27 11:48:49.947 E/AndroidRuntime(24752): at android.os.Handler.dispatchMessage(Handler.java:98)
02-27 11:48:49.947 E/AndroidRuntime(24752): at android.os.Looper.loop(Looper.java:164)
02-27 11:48:49.947 E/AndroidRuntime(24752): at android.os.HandlerThread.run(HandlerThread.java:65)
02-27 11:48:49.947 E/AndroidRuntime(24752): Caused by: java.lang.ClassNotFoundException: Didn't find class "androidx.core.app.ActivityCompat" on path: DexPathList[[zip file "/data/app/POC.Android-7T7qHKq5GovafVYR7Qfq4w==/base.apk"],nativeLibraryDirectories=[/data/app/POC.Android-7T7qHKq5GovafVYR7Qfq4w==/lib/arm, /data/app/POC.Android-7T7qHKq5GovafVYR7Qfq4w==/base.apk!/lib/armeabi-v7a, /system/lib, /system/vendor/lib]]
02-27 11:48:49.947 E/AndroidRuntime(24752): at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:93)
02-27 11:48:49.947 E/AndroidRuntime(24752): at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
02-27 11:48:49.947 E/AndroidRuntime(24752): at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
02-27 11:48:49.947 E/AndroidRuntime(24752): ... 7 more
Unhandled Exception:
Java.Lang.NoClassDefFoundError: Failed resolution of: Landroidx/core/app/ActivityCompat;
Thanks in advance for any information and help you're able to provide!
Best wishes,
Alexander.
Desperately waiting for AndroidX libraries. I am in the same situation for the last 3 months.
Hi @basiljohntme,
Not that it's truly an answer to our question, but I managed to find a work-around for my issue and now, once again, have a working and updated partner SDK. It's probably off-topic to explain how I did this here, but in the hope of helping others, here goes:
- Download the AndroidX.Core library and its dependencies from the Maven-repository.
- Create a new directory and unpack all downloaded JAR-files into that directory.
- Open the AAR-files with an archiver-tool, extract their
classes.jar-files, and place the contents of the latter in the above directory as well. - Run "jar cvf androidx.jar ." within the aforementioned directory to package all AndroidX-files together in a new JAR.
- Add this JAR to your Android binding-project as an embedded reference JAR.
- Add your binding to an Android App project, and try to build it. You'll probably get some build errors related to duplicate class inclusions. Remove these files from the directory created in 2 and repeat steps 4 & 5 until there are no such errors left.
- Create/build your NuGet. You should now be able to successfully run the code contained in the partner SDK.
Hi @AlexanderMelchers , thank you so much for the suggestions. I will go through these steps. I have another dependency on WorkManager as well.
Would you be able to tell us which libraries you're using that are depending on AndroidX? This seems super premature for vendors to be already taking a dependency on it, especially something like WorkManager which is not even stable yet.
We're working on preview nuget packages of AndroidX, BUT you won't be able to do much with them in apps that have any other dependencies which are compiled against Android Support until we complete the migration tooling (which we are also working on).
In the native SDK, they have used WorkManager libraries like android .arch.work » work-runtime, android.arch.work » work-firebase & android.arch.persistence.room » runtime
Hi @Redth,
Unfortunately the vendor we're partnering with is big enough to be at the forefront of technological development (and occasionally advance new public technological change of itself). That means that they've already made their SDK ARM64e (iOS) compliant as well, and now they've moved to use Android X. Why isn't exactly clear to me, as indeed doesn't seem to have any significant public reception yet and all they're using it for appears to be to show a permissions dialog from within the SDK using androidx.core.app.ActivityCompat...
All the best,
Alexander.
There is one suggestion that comes to mind which is to 'dejetify' the .aar they use. @SotoiGhost is doing some work around using the jetifier in our build process. He can share how you could manually invoke that command.
As Redth said, the Google's jetifier tool gives the ability to "de-jetify" your library. To do so, you just need to download the jetifier-standalone tool and run the following command:
./jetifier-standalone -i <source-library> -o <output-library> -r
The -r option indicates that you want to de-jetify the library instead of jetify it.
You can learn more about this here.
Hope this helps you.
Best!
Israel Soto.
Hi @SotoiGhost,
Thanks for the info! Although for the time being our own solution of adding the missing Android X references as an embedded reference JAR seems to work fine, it's good to know we have alternatives when we next run into trouble with this.
All the best,
Alexander.
Closing.