181106 Added: Modify the third-party libraries that failed to be migrated

Introduction to AndroidX

Check out the introduction to Android X in the Android documentation

Androidx is a modified version of the Android.support. XXX package. The previous support package was too confusing, so Google introduced androidX.

Since support upgrades and maintenance will be phased out in future releases, we will have to migrate to androidX. The official description is as follows:

Existing packages, such as the Android Support Library, are being refactored into AndroidX.
Although Support Library versions 27 and lower are still available on Google Maven,
all new development will be included in only AndroidX versions 1.0.0 and higher.
Copy the code

2. Migration steps

2.1 modify the gradle. The properties

android.useAndroidX=true
android.enableJetifier=true
Copy the code

Among them:

  • android.useAndroidX=trueIndicates that the current project is androidX enabled
  • android.enableJetifier=trueIndicates that the dependency packages will also be migrated to AndroidX. False indicates that dependencies are not migrated to AndroidX, but there may be problems with using the contents of dependencies. Of course, this can be set to false if your project does not use any third-party dependencies

2.2 Migration

Click on the official migration guide

Do the following in AndroidStudio 3.2 or later (currently 3.2, alpha) :

  • Refactor > Migrate to AndroidX


    image

When we do this, we are reminded whether to package the current project as a backup. If you’ve made a backup ahead of time, ignore it; If no, back up the data first.

3 Migration Follow-up

3.1 Manually Changing the Error Package Name

After Migrate to AndroidX, some controls will have problems converting package names/pathnames, so manual adjustments will be required (including modifying XML layout files and.java/.kt files).

Such as: ViewPager RecyclerView etc., the content after the migration, the package name is androidx core. Weight. XXXX, this is a mistake of package names, we have to manually modify, otherwise, Failed to compile properly – clicking the green Run button details what went wrong.

Note that the build TAB in AndroidStudio can only report up to 50 errors at a time!! So, maybe after you’ve done the first batch, you’ll have N more 50s. Keep a calm 💗 here.

3.2 Fixing errors in DataBinding (duplicate ID error)

On AndroidStudio3.2 + AndroidX, error checking and handling are more stringent. If there is an ID of the same name in the same XML layout file, in the previous version, we can compile and run normally, but in the new environment, we must report the error message:


image

In the error message above, we use DecibelBinding as an example to outline the repair process.

  • As shown above, the inability to apply xxxBinding from the xxxBinding constructor to the specified type indicates that the wrong Binding class is DecibelBinding

  • DecibelBinding for DataBinding is decibel.xml. DecibelBinding for DataBinding is decibel.xml. So global search)

  • Now that we have identified the XML, we still need to know what went wrong, so we continue to look at the error in the diagram: symbol not found symbol: variable XXX. This variable is the ID name of the control.

  • DataBinding’s rule for converting control ID names is to strip away underscore hyphens and capitalize the first letter after the original underscore. So, in the figure fragmentDiscoverGridItemRelativeLayout1 corresponding control id should be: @+id/ fragment_DISCOVER_GRId_ITEM_relative_layout, followed by a 1 because it is duplicated. We then search the corresponding XML file for the control name and remove the duplicates.

3.3 Removing duplicate attribute names in attr.xml

Before moving to AndroidX, we can write custom properties for custom controls with the same name as the existing properties on Android. However, under AndroidX, we can not write custom properties with the same name as the existing properties on Android. But the translation is repeated to define attr/ XXX).

  • Examples of errors:
<declare-styleable name="RoundImageView"> ... <! -> <attr name="textSize" format="Integer" />... </declare-styleable>Copy the code
  • The correct sample
<declare-styleable name="RoundImageView"> ... <! <attr name=" Android :textSize" />... <attr name=" Android :textSize" />... </declare-styleable>Copy the code

As for the same name attribute, it is not known on androidX which control contains a mode attribute, so if you have attr/mode in your custom control, you need to manually change it to another one.

Notes in 3.4 Glide are not compatible with androidX

After migrating to androidX, Glide used in android. Support. The annotation. CheckResult and android support. The annotation. NonNull the two annotations to the migration. Previously, some users mentioned the issue in Glide: github.com/bumptech/gl…

In the above issue, a user reported that Glide can migrate normally after upgrading to 4.8.0. But not on my end. I then upgraded Glide and added support-annotation to the Gralde file so it would compile properly. It looks like full compatibility with androidx will be completed in a future Glide 5.x release.

My temporary solution:

/ / picture to load - Glide implementation "com. Making. Bumptech. Glide: Glide: 4.8.0 annotationProcessor "Com. Making. Bumptech. Glide: the compiler: 4.8.0 / / CnPeng 2018/9/26 these two lines are designed to solve the chariot in the afternoon The annotations in the https://github.com/bumptech/glide/issues/3185 - Glide hasn't fully compatible with androidx implementation "Com. Android. Support: support - annotations: 28.0.0 - alpha3" annotationProcessor "Com. Android. Support: support - annotations: 28.0.0 - alpha3"Copy the code

3.5 Standard Package Name (Folder Name)

By package name, I mean the folder name in the project. In previous versions, we might name packages in uppercase letters, which didn’t comply with the Java naming convention, but at least compiled and ran properly. However, after upgrading to the AndroidStudio3.2 + androidX environment, you must strictly follow the naming conventions; otherwise, errors may be reported, resulting in improper compilation and running.

Examples of errors:


Correct examples:




The naming conventions for package names do not seem to be very strict. Because I found that some entries with uppercase letters were compiled with an error and some were not. But it’s always better to follow the rules!

3.6 Modifying a Third-party Library that is not automatically migrated

181108 Add-on: Although we have configured the parameters from Gradle to migrate the tripartite libraries, the migration may fail due to the version update of the tripartite libraries. If data binding is used when tripartite library migration fails, the following error is usually reported:


After encountering the above errors, we can handle them as follows:

  • 1. In gradle file, upgrade the upgradable tripartite libraries (usually, upgradable tripartite libraries are shown in yellow)
  • Create a new project and copy all of gradle’s dependent libraries to the new project. Then copy all of gradle’s dependent libraries to the new project. (The actual operation can be carried out in a dichotomy way, copy half of the dependent libraries at a time, and then compile). Then it can be targeted