Fix annotation dependency

[blasten]

Description

These plugins don't explicitly depend on androidx.annotation. In some cases, they relied on their transitive dependencies to include the dependency.

Fixes flutter/flutter#35239, flutter/flutter#36400

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[collinjackson]

@tagesholly1 I'm curious why you reacted 👎

It looks like this might fix flutter/flutter#35239, flutter/flutter#36400. I've added that to the description

[amirh]

I wonder whether it's better to just remove the 2 usages of the annotations, at least until we fix Jettifier, to prevent apps that didn't migrate to androidx from blowing up when using this plugin. However I'm not sure I understand the condition for when gradle blows up? I just tried to depend on this plugin from an app that wasn't migrated to androidx and it seems to work.

@blasten do you happen to know when Gradle blows up? would it reduce build failure for some apps if we don't include this dependency?

[blasten]

I wonder whether it's better to just remove the 2 usages of the annotation.

For all 1P plugins?

do you happen to know when Gradle blows up?

Yeah. The issue occurs when a plugin relies on any api transitive dependency listed here and then one of these cases happen:

Case 1

\--- App
    \--- Plugin A
         \--- Maven Dependency B
              +--- com.android.support:support-annotations:1.0.0

Plugin A imports android.support.annotation.NonNull, expecting that Maven Dependency B will always contain that api dependency.

A developer decides to migrate App to AndroidX, which means Android's auto migration tool "Jetifier" will translate android.support.annotation.NonNull into androidx.annotation.NonNull. The built is broken. Building the plugins as AAR fixes this problem.

Case 2

Similar to case 1, but in this case we update a plugin to use an AndroidX dependency e.g. androidx.annotation.NonNull, but it still relies on "Dependency B", which provides android.support.annotation.NonNull instead. This works today because the example app that each plugin has also uses AndroidX, which then enables Jetifier auto translation. However, if the App developer isn't using AndroidX, then the build fails indicating that androidx.annotation.NonNull is undefined.

Case 3

Similar to case 1, but in this case "Dependency B" upgrades to "AndroidX" and doesn't bump the major version. Now, the plugin is broken.

Solution

Relying on api/compile transitive dependencies is "dangerous" IMO. This seems to be a common pattern in Android development though. In the meanwhile, building the plugins as AAR fixes these issues because Jetifier can operate at the plugin level and translate all references.

[amirh]

LGTM