Problem :
I have two Android binding libraries in my solution(C#) and each one of them has specific set of .jar files referring, and these .jar files are from 3rd party. When any one of the binding library is added to the solution then all the classes and interface defined in the .jar files are detected during compile time and everything works perfectly fine but if I add both binding libraries to the solution then there is a conflict between some of the .jar files in both of the binding libraries. Classes, interfaces were not detected and also says assembly reference is missing.
What I have tried ?
1. I have tried putting each of the binding libraries in two different C# library projects and then referring the C# wrapper libraries not directly to the android binding libraries but it is still showing up the same error.
2. I have tried to load the binding libraries using reflection during run-time but I cannot do that because I need to implement interface present in .jar file to my c# class.
Can you please help me how do I resolve this ?
Thanks,
Related
I'm setting up a Kotlin multiplatform project so I can reuse common code in multiple platforms for a single app. While building the common code for the app, I've extracted some base classes that I'd like to be able to reuse as a library in multiple multiplatform projects. I'm trying to add the library as a dependency in commonMain. There are a couple of things I don't understand.
First of all: is this currently possible?
If yes:
The default stdlib-common is a jar file, correct? How come a jar can be referenced as a dependency in commonMain if no Java can be used there? Or is it okay to use a jar compiled from pure Kotlin, as long as it only has Kotlin dependencies?
How do I compile a pure Kotlin jar that can be used in commonMain the same way as stdlib-common is used? Are there any sample build.gradle projects or guides for how this should be packaged?
If no:
What options do I otherwise have to reuse code over multiple multiplatform projects, if I want to avoid duplication? Do I actually need to keep all source within the actual commonMain source folder? Can it be linked from another folder if so? I tried adding additional content roots but it didn't seem to work since Gradle controls the configuration and I'm not sure how to add additional content roots in commonMain through Gradle.
Thanks in advance.
I got it working, mainly from looking through this thread and looking at this example. Although some of it might be dated by now, it helped me understand the following:
MPP1 can have another MPP2 as a dependency. Here is a list of MPP libraries for reference.
MPP2 needs to generate artifacts for the same set of platforms as it is used in by MPP1.
MPP2 generates platform artifacts along with a module file where they are described. MPP1 can then use the below configuration. Thanks to the module file, it's not required to explicitly add each platform's corresponding dependency, the dependency only needs to be declared in commonMain.
commonMain {
dependencies {
implementation kotlin('stdlib-common')
implementation 'com.company:mpp2:1.0'
}
}
I've been developing a library to use in my project, and while it is working locally, I would like to share it and use it as an external dependency.
How do I wrap my library so that built AAR contains both *.so native library and generated *.java classes (generated by Kotlin compiler) ? Because there are two-way interactions in my library: Kotlin external functions defined in C++, and some C++ code calling Kotlin classes and methods.
So, my questions are:
How to correctly package Kotlin + JNI android library ?
How to upload said package to Bintray so users (and myself) could use it as a dependency ?
(Note: I've seen tutorials and examples, but they were either Kotlin/Android or Java/Jni/Android)
If you want to package .so with your application, note that you can always put it inside JAR file. Then, you can unpack it, and load it using System.load.
You can find sample here: https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo031
Note
Remember that packaging .so inside application is a risky thing. As you deal with native code, you have to be 100% sure that all native dependencies are there. You have to pay attention to architecture as well.
I am working on writing an SDK for a client. Part of the SDK requires me to interface with a good 20-30 endpoints. How I have always done this in the past is simply used Retrofit and OkHttp for the API interface. I recently discovered, however, that you cannot use 'nested' library references within a library.
My question is, how do I go about using Retrofit in this current library I am making so that it can be used on other devices? Do I just need to clone the repo, copy the code into my project and go from there? Or is there a simpler method?
Thanks all.
Your can use maven transitive dependency.
Or AAR have no problems with nested jar files. From documentation
A library module can include a JAR library
You can develop a library module that itself includes a JAR library; however you need to manually edit the dependent app modules's build path and add a path to the JAR file.
I use this approach for okhttp.
I'm having problems with the #StringDef support annotations. They work perfectly fine when the library they are in is part of the project (not an .aar file), but when I compile the library as .aar files and try to use them in another project, the annotations aren't enforced.
http://tools.android.com/tech-docs/support-annotations
Under the section "Using annotations in your own libraries" it says
If you annotate your own libraries with these annotations, and use Gradle to build an AAR artifact, at build time the Android Gradle plugin will extract annotation information and ship it inside your AAR file for use by clients of your library. You can take a look at the annotations.zip file inside the AAR where the information is recorded; this is using IntelliJ's external annotations XML format. This is necessary because .class files cannot contain enough information about annotations to handle the #IntDef information above; note that we need to record a reference to the constant itself, not its value. The Android Gradle plugin will run the extract annotations task as part of the build if (and only if) your project depends on the annotations support library. (Note that only the source-retention annotations are placed in the .aar file; the class level retentions are kept in classes.jar.)
I opened up the .aar file and inside there is the annotations.zip file, and if I extract that, there's an XML file that has all the correct annotations.
I'm using the #Retention(RetentionPolicy.SOURCE) as it says I need to
The app that I'm trying to use these in as .aar files does have a dependency on the support library compile 'com.android.support:support-annotations:23.1.1
What am I missing to make these work?
Edit: I double checked that the project using these as .aar files also has the annotation processor turned on.
The issue was the interfaces were private.
For some reason a private interface works properly when a library project is compiled by it's host project as a sub module.
When the library project is used as an .aar file, the private interface no longer works.
As mentioned here, the information about constants used as #StringDef/#IntDef values will be lost once it is compiled into aar file. What remains is just values of the constants.
#IntDef annotations cannot be class retention because the thing they need to record (which constants are valid) cannot be expressed in the .class file -- the only data stored there for an annotation is the value of the constant, not some sort of pointer to the constant itself.
I want to create an Android jar library which has activities which use layouts that are all within the jar file.
I have been researching and trying different methods for the last few days and exhausted the related posts here. I have managed to get drawables and other raw assets to reside and be loaded from within the jar. However I have not been able to include valid resources which include the layouts. The official view is that it is not supported yet however I am sure it can be done.
I see that this is possible with .aar libraries when using Gradle but I am unsure if .aar libraries are compatible with older Android projects.
Could anyone shed some upto date info on this issue of resources/layouts in jar libraries and also the compatibility of .aar libraries.
Many thanks
I want to create an Android jar library which has activities which use layouts that are all within the jar file.
That is not possible, sorry. However, you are welcome to create an Android library project that serves this role, and that library project can ship a JAR instead of Java source code (see the Play Services SDK's library project for an example). The layouts would not be inside of the JAR file, though.
The official view is that it is not supported yet however I am sure it can be done.
I am sure that you are incorrect in your assessment.
I see that this is possible with .aar libraries when using Gradle but I am unsure if .aar libraries are compatible with older Android projects.
Project age has nothing really to do with it. If you are using Gradle, AAR files work. If you are not using Gradle, AAR files do not work.