Add-to-app release features

[xster]

Extracting some discussion items out of #3554 for release tracking.

• Let the AndroidX setting follow the parent project's AndroidX setting P1
• Just do include_flutter.groovy for now P1
• The auto integration probably needs to add compileOptions {
  sourceCompatibility 1.8
  targetCompatibility 1.8
  } to the host app's build.gradle too P1 Use Build Variants view to control Flutter build mode #4134
• Resurface the flutter attach button in the toolbar P1
• Let the user choose the directory when creating new modules P2 Use Build Variants view to control Flutter build mode #4134
• Choose the debug/profile/release mode of the AAR built when building an AAR from the menu ** P2 ** Done via Build AAR for all build variants by default flutter#44797
• If only one Flutter fun config exists then the Flutter attach button is active even if it is not selected P2 Use Build Variants view to control Flutter build mode #4134

And when flutter/flutter#32999 makes it in:

• Let flutter attach monitoring start as soon as the Android host app is launched to allow hot reload on Dart file save when the user navigates into the Flutter screen. P2

[devoncarew]

@stevemessick, should we break these out into individual issues? That may be helpful if some items have different priority, and or may land in different releases.

[xster]

Thanks. Commented inline.

[stevemessick]

Thanks @xster, that helps.

[xster]

One more note that @matthew-carroll just noticed. It would be nice (for Flutter modules in general) to be able to choose the debug/profile/release mode of the AAR built when building an AAR from the menu (might already be possible?). P2

[stevemessick]

I added that to #4064

[xster]

Thanks for the demo plugin @stevemessick

I tried it a bit. It's much smoother than the last one. A few more observations

• In the outer app's settings.gradle, include ':flutter_module' appeared multiple times, though it's probably inconsequential

• The Java 8 compileOptions wasn't added in the outer app's build.gradle. The build fails to compile until added manually

• The Flutter attach is waiting for a service connection even though the Flutter screen already launched

Perhaps the IDE side work-around for Flutter attach on Android had some full-Flutter specific assumptions in it. Either way @blasten's generic flutter_tools side fix for Flutter attach seems like it'll be in momentarily flutter/flutter#44637

• I had to switch the build configuration from the Android build target to the Flutter build target in order for the Flutter attach menu and toolbar options to be come enabled.
  

Is there a way to have it always available as long as there is a Flutter build configuration present?

Thanks so much!

[stevemessick]

Glad you were able to use that plugin @xster.

In the outer app's settings.gradle, include ':flutter_module' appeared multiple times, though it's probably inconsequential

I'm planning to clean that up. Thanks for the reminder.

The Java 8 compileOptions wasn't added in the outer app's build.gradle. The build fails to compile until added manually

I wonder what we're doing differently? I always get this:

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

I can add a check to ensure it is included.

The Flutter attach is waiting for a service connection even though the Flutter screen already launched

I think the flutter attach has to occur before launching the Android app, at least with the sample code I use. I just created a sample Android app and Flutter module. Here's a screenshot of stopping at the canonical breakpoint:

I'll take another look once flutter/flutter#44637 lands.

I had to switch the build configuration from the Android build target to the Flutter build target in order for the Flutter attach menu and toolbar options to be come enabled.

Yeah, that's WAI but your suggestion sounds like a better way to do it. Shouldn't be difficult.

Thanks again for the feedback!

[stevemessick]

Yeah, that's WAI but your suggestion sounds like a better way to do it. Shouldn't be difficult.

Oops, I forgot that the run config is actually used in the flutter attach. We get the command-line options from it. You could have multiple Flutter run configs to do different things and we need to know which one to use. So I think this needs to stay as it is.

[xster]

I wonder what we're doing differently? I always get this:

I used the new Flutter module rather than import Flutter module if that makes a difference.

flutter/flutter#44637 is now merged (though temporarily reverted, but it should go back soon. You can just check out a32fc986f directly too).

Flutter attach now connects correctly either before launching the Android app or after :D

It did surface one change I think we should make. For the CLI, I'm attaching a small video to demonstrate.

https://streamable.com/waxnw

The behavior we'd want is for the attach session to be persistent across app relaunches until the user explicitly decides to disconnect. It works in the CLI, but the IntelliJ plugin and VSCode currently disconnects permanently once the app closes. Could we keep it alive?

Oops, I forgot that the run config is actually used in the flutter attach.

Is there a way for the plugin to detect that only a single Flutter config exists, if so, then default to that one? If multiple Flutter config exists, then we can ask the user to select one but that should be rare.

[xster]

Mirror issue for the attach on VSCode Dart-Code/Dart-Code#2115