The dreaded NativeScript 2.0 Android plugin problem and why it will affect everyone not just plugin developers

UPDATE (04/17/2016): Our prayers have been heard and the {N} team decided to continue support of the current plugin structure with AndroidManifest.xml in the plugin’s platforms folder in addition to the new .aar structure. You can read more about it here.

As a {N} plugin developer last week it was brought to my attention that there are major breaking changes coming to the platforms/android folder. You will probably think that as a plugin user this does not affect you in any way. Well actually it does affect you and I will outline below why it probably be a breaking change for any plugins you use that have some platform specific permissions/resources for android.

Let’s first look at what this change is all about: The {N} core team decided to remove the current ability for plugin developers to include required changes to AndroidManifest.xml and/or used resources in the res folder. And instead of that the ONLY way they added for us to do that is via a precompiled .aar file which should be distributed with the plugin.
But why is this such a problem for plugin developers? As an example I will use the nativescript-contacts plugin to which I contributed.

Workflow pre-2.0

This plugin requires some permissions on android to write and read contacts. Initially it was only reading contacts so in its manifest file there was only the READ_CONTACTS permission. I then added saving of contacts which required two more additional permissions WRITE_CONTACTS and GET_ACCOUNTS. So after I wrote the actual code for saving all I had to do was just to add the appropriate XML in the AndroidManifest.xml and submit the pull request. Then the repo owner would clearly see what this change is and why it was needed.

Workflow 2.0+

So I just finished implementing the logic and need to add the appropriate permissions so the plugin is Plug’n’Play for any plugin end-user. In order to do that first the repo owner would have to have created a separate android project that is setup to be compiled as an android library – it can be either in some other repo or in most cases in the same repo but in some separate folder. Ok, I manage to somehow find where the AndroidManifest.xml file is and add the needed permissions. But wait I’m not done yet. Remember we need an .aar file. So in order to get that file I need to compile this project first. Since I don’t have Android Studio we will use simple gradle to compile. So we have the long sought .aar file. But we are not finished yet. This .aar file is located in the build folder of the other project. So we need to move it under the platforms/android folder of our plugin. Now we are finally done and we can submit our PR to the owner. But the work is not yet finished. Now the repo owner needs to verify my pull request. He checks the code and all looks ok, then comes the .aar file. Ok since it is a binary file he sees that it was changed, but what exactly was the change compared to the previous one? Difficult to find out. He would only assume that I did not do anything wrong or bad. You can see what I’m talking about in the nativescript-calendar plugin which was updated to the new and “better” structure.

So to sum it up: for adding up 2 lines in the AndroidManifest.xml file I additionally had to perform manually 4 steps:
1. Find the manifest file “hidden” inside a different folder structure
2. Build the separate project
3. Find the .aar file in the build folder of the separate project
4. Replace the .aar file in the correct plugin folder

In the era where we have self-driving cars, I think that’s a bit to manually 🙂 Not to mention the overhead it creates from developer point of view.

How does this work with other similar frameworks?

For cordova the plugin has a special config.xml file which can include manifest file additions.
For ReactNative developers have special folders where they can put the plugin’s native iOS/Android code and files.

Conclusion

There has been a big discussion about this issue with many plugin authors trying to explain the situation I outlined above and proposing different solutions. I even ended up submitting a PR with one possible fix with the tradeoff to make the build a bit slower. But all of this just hit a brick wall and came to no avail with no reasonable explanation.

So many plugin developers will remove the manifest file to make their plugins compatible for 2.0 and will write in the readme of the plugin that users need to add this and that to their application manifest file. This is where it affects you as an end-user of a plugin. If you oversee these details in the readme (or if you are a Telerik Platform user and add your plugins via the AppBuilder or Visual Studio interface) the plugin will just not work and your application will most probably crash. At this point send all your love to NativeScript 🙂