This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Fix the order of some Android X checks to avoid conflicts with Support v4 #2169
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #2168
A project that is migrated to Android X no longer has support v4 classes on its classpath... at least it seems so.
One can have a project migrated to Android X and thus is no longer able to import e.g.
android.support.v4.app.Fragmentin own code. If no 3rd party library is using the support v4 fragment compiling with AA 4.5.0 is no problem. Having a 3rd party dependency that uses support v4 does not mean you can use the classes in your code as there is a tool calledjetifierthat migrates the 3rd party code on the fly to use Android X. but during the actual build process the support v4 classes are still on classpath and so available to AndroidAnnotations.In the Android X support PR #2149 this was not known and thus we have some cases where the build fails with android x + support v4 libs on classpath.
This PR aims to fix the issue by changing order of checks so that Android X dominates support v4.