Enable Android integration tests in remaining plugins

[blasten]

Fixes flutter/flutter#86749

[stuartmorgan]

Looks like a number of these either aren't set up quite right or are failing tests; I think it would be easier to split them into one PR per plugin. (Looks like video_player worked, so that one we can land easily.)

[stuartmorgan]

I've been trying to do shared_preferences #4505, so if I can get that working we won't need a separate PR for it. I've failed quite a few times though (it's not clear to me how to run things locally the way FTL runs them, so iteration is very slow).

[blasten]

This was causing an issue in Android 11

[stuartmorgan]

For which scheme? It sounds like we may need to update the README.

[blasten]

Android manifests are aggregated. There's no need for manual instructions.

[blasten]

SENDTO works for SMS and emails

[stuartmorgan]

Android manifests are aggregated. There's no need for manual instructions.

Oh, I thought this was in the example app. I don't think we should add this here, because we don't know what schemes someone is going to use. We should instead document this query in the README for people who need it, as we are currently doing (but without this scheme). And then add this to the example instead, so that the test passes.

[blasten]

Done. I don't know why not adding them to the plugin AndroidManifest.xml automatically. I think the idea is to have 3p dependencies auto-configuring themselves when possible unless there's some major concern that prevents these from being the default.

I'm not sure if these concerns exist, or if we didn't know that the Android Gradle plugin merges manifests automatically.

[stuartmorgan]

I don't know why not adding them to the plugin AndroidManifest.xml automatically.

It is entirely possible to use url_launcher without any permissions (just use launch without canLaunch), and almost nobody would use the entire set of possible queries that canLaunch could require. We shouldn't force people using a plugin to have their app require permissions they aren't using. Especially since the guidance from the stores is always to use the minimal permission set.

if we didn't know that the Android Gradle plugin merges manifests automatically

I didn't know that certainly, and it's good to know 🙂 . We should audit our READMEs for cases where the advice is "you must add X if you use this plugin" rather than "you might need X if you are using this plugin to do Y", and for the former, put it in the plugin manifest.

[blasten]

I haven’t used this plugin, but if canLaunch isn’t required, then the API seems very confusing. I assumed that canLaunch means that if it returns false, then never launch the intent, and handle it differently.

[stuartmorgan]

Updating the docs is on my TODO list, because the example shown in the README (await canLaunch(_url) ? await launch(_url) : throw 'Could not launch $_url';) is pointless; it's just a slower and more cumbersome way of writing

if (!(await launch(_url))) throw 'Could not launch $_url';

and handle it differently

This is where canLaunch is actually useful, yes. But with https URLs, for instance, I would be willing to bet that nobody has fallback code in their application that handles the case where someone's device does not have a browser, so calling canLaunch in that cirumstance is pointless.

[blasten]

@stuartmorgan this is ready for another review

[stuartmorgan]

Looks like camera is still broken. Per my earlier comment: is there a reason not to split that out so we can land the rest now while that's worked out?

[stuartmorgan]

For which scheme? It sounds like we may need to update the README.

[stuartmorgan]

LGTM with some nits. Thanks for getting all of these working!

[stuartmorgan]

Why don't we need this?

[blasten]

The default implementation of onClosed does nothing. For callbacks, I'd be very surprised if there was an API that has a super implementation that does something. It'd be incorrect to call it a callback.
https://developer.android.com/reference/android/hardware/camera2/CameraDevice.StateCallback#onClosed(android.hardware.camera2.CameraDevice)

[stuartmorgan]

@blasten I wrote up https://github.com/flutter/flutter/wiki/Plugin-Tests#enabling-android-ui-tests based on everything I learned from my trial and error on shared_preferences and from your PR. Please edit it if you think anything is missing or misleading.

(My goal is to eventually make all of this part of the plugin template, but until then I want to make sure the process for all of our non-trivial test setup is clearly documented.)

[blasten]

@stuartmorgan yup. That's pretty much it