Fix build issue caused by appcompat 1.4.0.-beta01 release

[ucsbricks]

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Documentation changes
• Other... Please describe:

PR Checklist

For bug fixes / features, please check if your PR fulfills the following requirements:

• Testing has been carried out for the changes have been added
• Regression testing has been carried out for existing functionality
• Docs have been added / updated

What is the purpose of this PR?

This PR restores the ability to build apps using this plugin after androidx.appcompat:appcompatwas release in version 1.4.0-beta01.

Does this PR introduce a breaking change?

• Yes
• No

What testing has been done on the changes in the PR?

• Plugin was re-added and build was performed using Android Build Tools in Version 30.0.3.

What testing has been done on existing functionality?

• Changes should have no influence on existing functionality as it still uses the same framework versions as before it broke.

Other information

[ath0mas]

→ Instead should there be 2 distinct versions (and preferences?), one for legacy and another for appcompat ?
Given that Legacy is mostly locked into 1.0.0, and that Appcompat is giving example of being active but breaking things between non-major versions, stable 1.3.1 and beta 1.4 😞

→ Maybe set 2 exact versions instead of dynamic dependency versions like 1.+?
Gradle itself suggests to use Dependency locking:

Use of dynamic dependency versions .. makes builds non-deterministic. This causes builds to break without any obvious change ..
To achieve reproducible builds, it is necessary to lock versions ..

→ Finally I would go for a new cordova.plugins.diagnostic patch release with this fix, setting locked versions to the "previous" ones, those before recent breaking updates, and then a new major release to start compatibility for sdk 31+ only or so (since appcompat 1.4 seems to be).

[dpa99c]

@ucsbricks thanks for this. I think the idea of @ath0mas to separate into 2 separate plugin variables makes sense. I will push out a patch release to do this ASAP.