We write the plugin for Unity correctly. Part 2: Android

We write the plugin for Unity correctly. Part 2: Android  
 
In previous part we covered the main problems of writing native plugins on Unity for iOS and Android, as well as methods for solving them for iOS. In this article I will describe the main recipes for solving these problems for Android, trying to maintain a similar structure of interaction and the order of their consideration. github.com/googlesamples/unity-jar-resolver . This package can be downloaded independently, and it also comes with Google Play Services and Firebase. The idea is that in the Unity project we create xml files with a list of the dependencies required by the plugins syntax, similar to the definition in build.gradle (with the specification of the minimum versions):
 
 

extra-google-m2repository
extra-android-m2repository
extra-google-m2repository
extra-android-m2repository
extra-google-m2repository
extra-android-m2repository
extra-google-m2repository
extra-android-m2repository

 
Next, after installing or changing the dependencies in the project, select Assets → Play Services Resolver → Android Resolver → Resolve from the Unity menu and voila! The utility will scan xml declarations, create a dependency graph, and download all required dependency packages for the desired versions from the maven repositories in Assets /Plugins /Android. And it marks a downloaded file in a special file and replaces it with new versions the next time, and we will not touch those files that we put. There is also a settings window where you can enable automatic resolution of dependencies, so as not to press Resolve through the menu, and many other options. To work requires Android Sdk, installed on the computer with Unity and selected target - Android. In the same file, you can write CocoaPods dependencies for iOS builds, and in the settings, set Unity to generate xcworkspace with dependencies enabled for the main XCode project.
 
 
Unity has recently become a full-fledged support gradle collector for Android, and ADT has announced as a legacy. There was an opportunity to create a template for the gradle configuration of the exported project, full support for Aar and variables in manifest, merge manifest. But third-party sdk plug-ins have not yet managed to adapt to these changes and do not use the features provided by the editor. Therefore, my advice is better to modify the imported library for modern realities: remove dependencies and declare them through xml for Unity Jar Resolver, compile all java code and resources in Aar. Otherwise, each subsequent integration will break down the previous ones and take more and more time.
+ 0 -

Add comment