This article has been published exclusively by the official wechat account hongyangAndroid
preface
It is well known that Android provides many Support libraries as API supplements, such as SupPRT-V4, V7, etc., but I found that these Support libraries are numerous versions, and the content involved is quite complex. This article takes you through the common Support Library. The second half of the article then delve into an error that we often encounter when using open source libraries with v4 duplicate dependencies: DexException Multiple dex Files define.
Why support libraries
Why does Google need so many support libraries, why not just put them in the SDK? There are three reasons to refer to official documentation:
1. Backward compatibility for example, our App needs to support minSdkVersion=9, targetSdkVersion=11, and uses the ActionBar class provided by Android 3.0 (API Level 11) in the program. Apk was successfully compiled with compileSdkVersion=11. It runs perfectly on An Android 3.0 device, but the app crashes on an Android 2.3 device, reporting that the error of the ActionBar cannot be found. This makes sense because there are no new classes on the old version. In order to avoid the embarrassment that apps developed with the latest functions can only run on devices with the latest operating system, the authorities have put the newly added interfaces of the new system framework into the Android Support Library (Support package). When developers encounter the above situation, You can use the same ActionBar class from the support pack, which is packaged into the App, so that apps that use the functionality on the new version of the OS can also be backward compatible with older versions of the device. In addition to saving us from judging the system version on which the App is running, using the classes in the support pack allows us to maintain the same user experience across versions of the App. For systems below 5.0, material Design is used.
2. Provide functionality that doesn’t fit into the framework
Android officially provides recommended design for App development, hoping that Android applications have relatively consistent interaction design to reduce user cost, and hope that third-party apps similar to system applications can be perfectly integrated into the Android ecosystem. However, these are only recommendations, and developers are not required to do so. If they do, they can use the features provided by the official support pack to avoid reinventing the wheel. This is the case with DrawerLayout, Snackbar, and other classes in support packages.
3. To support different types of devices
Use support packs to provide functionality on different forms of devices, such as mobile phones, TVS, wearables, etc.
Support – library support library
The Android support library provides a lot of functionality that is not built into the framework. These libraries provide new functionality for backward-compatible versions, useful UI elements not included in the framework, and a range of utilities that applications can leverage. Such as
Material Design is a new function added in Android 5.0, but many devices are still running Android4.0. It is obviously unreasonable to set minSdkVersion to API21 for Material Design. In order to use Material Design for devices running Android5.0 or below, you should use support-library, including the previous Fragment and now the permission check, which is the same principle!
The Android Support Library includes the following dependency packages: 1, 2, and 3
Support – the v4
Android 2.2(API Level 8) and below will be removed from the Support Library for API Level 4. Therefore, starting from Android Support Library 24.2.0, the V4 package supports the lowest version of Android 2.3, namely API Level 9), and divides the V4 Library into 5 parts, which can be referenced in the project as needed, but the necessity is not very great. First, because these 5 parts have dependencies, second, compat library takes up half of the size of V4 library, V4 library dependency graph:
Fragment: a class designed to solve Android fragmentation that allows you to adapt the same application to different screens. NotificationCompat: Supports richer forms of notification; LocalBroadcastManager: Suitable for in-application messaging. ViewPager: A viewgroup that manages sub-views and allows users to switch between views. This is used in many applications.
V4 is compatible with level9 prior to compileSdkVersion>9. ViewPager, for example, is only available in V4, not in SDK.
- How to use V4
compile 'com. Android. Support: support - v4:21.0.3'
Copy the codeAfter you have synchronized Gradle, right-click on ExternalLibrarys and select library Propertity.
support-v7
V7, like V4, also contains multiple dependencies, but unlike V4, the multiple subpackages under V7 are not split up later, but are released as separate libraries when they are first released. V7 is called V7 for Android 2.3(API Level 9) and above. It is called V7 for Android 2.3(API Level 9) and above. Also in Android Support Library 24.2.0, the lowest version of V7 Support was changed to Android 2.3 (API Level 9). These Support packages correspond to specific functions, and each can be referenced separately.
V7 app-Compat supports Action Bar interface Design mode, Material Design interface implementation, etc. Core classes include ActionBar, AppCompatActivity, AppCompatDialog, ShareActionProvider, etc
- How do I use V7
compile 'com. Android. Support: appcompat - v7:24.2.1'
Copy the codeThis Maven configuration of V7 automatically introduces the V4 library, so there is no need to import the V4 library. Compile ‘JAR file group (group/ namespace) : JAR file name (name) : JAR file version (version)’. Appcompat-v7, version 24.2.1 of the Android support library
Multidex Support Library
As your project gets bigger and bigger, you may find that one day your phone running below Android5.0 crashes. Class not found class not found class not found In fact, this is the famous application exception with more than 64K methods. The solution is this support library.
android {
defaultConfig {
...
minSdkVersion 15
targetSdkVersion 26
multiDexEnabled true}... } dependencies { compile'com. Android. Support: multidex: 1.0.1'
}
Copy the codeThen add the custom Application:
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
Copy the codeV4 supportLibrary delves into repeated dependencies
The following details a common v4 library duplication dependency problem, starting with two questions:
Does V7 include V4?
Why do I ask this question? I read a lot of articles about V4 online and came to the conclusion that V7 includes V4! Really??
Appcompat-v7 appcompat-v7 appcompat-v7 appcompat-v7 appcompat-v7
Create a new project and add v7 dependencies:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])The compile 'com. Android. Support: appcompat - v7:24.2.1'}Copy the codeTake a look at the project’s current dependency packages:
Sure enough, the project automatically introduces all packages under V4, v7 includes v4 meaning:
The compile ‘com. Android. Support: appcompat – v7:24.2.1’, gradle will automatically add all v4 package, and is of the same version and v7
Must the support library be consistent with compileVersion?
It’s not necessary. However, the official recommendation is to keep consistent, if the version is not consistent, it can still be compiled and run.
Duplicate dependency issues with V4 packages
As proved above, relying on V7 packages automatically introduces V4 packages, so if you rely on BOTH V4 and V7 in your project, will there be so-called double dependency compile errors?
The installation can compile and run successfully without error:
:mylibrary:preDebugUnitTestBuild UP-TO-DATE
:mylibrary:prepareDebugUnitTestDependencies
BUILD SUCCESSFUL
Total time: 7.005 secs
Copy the codeEven though different versions of the V4 package are imported at the same time, the compileSdkVersion will run fine.
Different versions of the V4 package were indeed introduced:
- Conclusion: If both v4 packages are imported in Maven’s way, Gradle automatically selects a higher version, such as 21.0.3, without causing conflicts.
Next, try maven importing the 21.0.3 V4 package and then importing the 19.1.0 JAR package locally:
Error: Dex file conflict
Of course, if lib is put in the same way as maven configuration V4 package version 21.0.3, this is ok.
Jar from aar, rename it supper-V4-21.0.3. jar and put it in the lib folder
- Conclusion: V4 dependency conflicts are actually between different versions of V4, and only when local lib and Maven introduce different versions
Abnormal conflict resolution
A project often introduces many open source libraries, and trying to unify all v4 versions of Moduler is not practical. You can only exclude some library V4 packages to ensure that only one version is introduced throughout the project.
1. First check the dependencies of various libraries of the current project:
2. Find the dependency libraries with conflicting versions, then search the app project, open source library lib directory, delete the corresponding JAR package and import it in the form of Maven.
3. If your app must import the V4 library using native lib, then exclude the V4 package from the open source library:
compile('com. Facebook. Fresco ": the fresco" : 0.10.0') {
exclude module: 'support-v4'
}
Copy the codeIf it is an open source library introduced in source form:
compile (project(':thirdpart:RecyclerViewAdapterLibrary')){
exclude group: 'com.android.support'
}
Copy the code