In the first three articles, some basic usage of Openatlas and the method of compiling patch aapt are introduced.
-Android plug-in development of Atlas first experience
-Android Plugin Development Atlas Build plugin Information list
-Compilation of the Atlas Resource Pack tool patch AAPT for Android plugin development
The Openatlas principle is to avoid the introduction of redundant libraries. That is, the host provides a third-party library, plug-in will not be introduced to the library, compile time in the form of provided to provide. The simplest example is the V4,V7 compatibility library, which should be avoided. To get my mom's plug-ins out of Openatlas, we can run them independently, but instead of compiling them into plugins, we use Android Studio's productflavors to adapt.
Before adaptation, all development is carried out in accordance with the normal procedure development process. Once the development is complete, we need to modify the Build.gradle file for adaptation. First of all we have to do is to increase the productflavors, wherein alone is representative can run independently, Openatlas is the plug-in representative.
{ alone{ } { } }
And our plugin, after versionname to join 0x10-0x7f between the value of the resource partition. The previous practice is to modify this property directly, and now we rewrite the property in Productflavors to complete the resource partition, just like this.
{ alone{ } { versionName "1.00x21" } }
and the corresponding dependence, when we compile alone, we have to pack the dependent libraries, but when we compile Openatlas, it is only compile-time provided, will not be packaged in, we use provided+flavor to achieve the purpose, take our previous scan QR Code project example.
dependencies {compile files ( ' Libs/zxing-core-3_2.jar ' ) Alonecompile ' com.android.support:appcompat-v7:22.2.1 ' openatlasprovided Files ( ' Libs/android-support-v4.jar ' ) openatlasprovided files ( ' Libs/android-support-v7-appcompat.jar ' )}
But the problem with this is that the provided method only supports jars, but if we use the Appcompatactivity class of the Compatibility Pack, we will inevitably use a resource file, when we compile the openatlas flavor, we need to remove the resource files.
As for the AAR, how to extract the jar, in fact, is very simple, the AAR decompression, the inside of the Classes.jar and the Lib directory Jar extraction processing can be.
One of the simplest examples is the theme file. It references the resource file Theme.AppCompat.Light.NoActionBar, which we want to remove. The procedure is also very simple, in the SRC directory under the new Openatlas directory, and create a new values directory, in the values under the new Styles.xml file, add, note that the plugin theme file in the host to exist, the simplest way is the host and plugin theme name is the same.
<resources> <style name="AppTheme" parent=""> </style></resources>
We see that we are simply turning the parent class into empty. This will not be an error when compiling the package. Android Studio will automatically merge our files. Other resource issues have also been dealt with similarly. The plugin is then generated. Plug-in information list generation, the introduction of plug-ins and so on. Similar to the previous article, it is no longer burdensome.
and plug-in generation remember to use flavor for openatlas generation, on the left of Android studio Click on Build variants to make changes
SOURCE download
http://download.csdn.net/detail/sbsujjbcy/9027641
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
The Atlas plugin adaptation for Android plugin development