Trouble importing Flutter module in 3.6.1

[xster]

Android Studio 3.6.1.
Plugin version 44.0.2.
Flutter master v1.15.23-pre.15.

Open https://github.com/flutter/samples/tree/master/add_to_app/android_fullscreen first in Android Studio (which already brings in the sibling flutter_module).

File->New->New Module...->Import Flutter Module
Select the sibling flutter_module folder.

Can't import. Says selected folder is not a Flutter module.

cc @stevemessick @redbrogdon

[stevemessick]

I downloaded samples-master.zip from github and unpacked it then tried to open android_fullscreen. I get an error:

Settings file '.../src/samples-master/add_to_app/android_fullscreen/settings.gradle' line: 4
A problem occurred evaluating settings 'AndroidFullScreen'.
> .../src/samples-master/add_to_app/flutter_module/.android/include_flutter.groovy (.../src/samples-master/add_to_app/flutter_module/.android/include_flutter.groovy)

flutter_module/.android does not exist. That's likely the problem; the importer looks for .android and displays that message if it is not found.

[xster]

Ah this makes sense. Wonder if we can show a "did you remember to run flutter pub get in your module folder if you just freshly cloned or downloaded it" type message for these specific types of errors.

[kenzieschmoll]

@stevemessick does adding a message sound like it could steer users in the right direction for this case? If so, let's let this issue track that.

[stevemessick]

@kenzieschmoll I'm trying to understand why .android wasn't checked in. @xster does the Flutter team recommend not including .android and .ios in source control?

[redbrogdon]

Author of that sample here. That was a recommendation made as I was building out the add-to-app samples. We tell devs to run flutter packages get from within the module project directories prior to using them. This ensures they have the latest configurations for all the Android and iOS subproject files.

If that's no longer the best way to go, I have no problem changing up how we do things. The samples should reflect the current best practice, whatever that may be.

[stevemessick]

Thanks @redbrogdon. I need to look into what happens in .android when a module is imported into an app by Android Studio. (Yes, I wrote the code but it was a while back.) I think we need to make a change to something, and if that's true it would suggest we need to do something different. It might mean changing the advice to include .android (or some part of it) in SCM or change flutter packages get to make whatever change is needed for the IDEs.

[stevemessick]

OK, I'm looking into this. When a Flutter module is imported into an Android app the module's :flutter Gradle project is added as a dependency to the app's Gradle project. That causes an *.iml file to be generated: .android/Flutter/fluter.iml.

That *.iml file has lots of references to generated files, which aren't checked in to the repo. It has lots of references to versioned libraries from androidx and io.flutter. If those versions are changed by upgrading Android or Flutter then the *.iml file won't be correct.

We need to figure out how best to handle this. I don't know, but I'd be glad if @xster and @redbrogdon could make suggestions. To me, it sort of looks like you have to use Android Studio to re-import modules into apps after upgrading either Flutter or Android.

EDIT: To be clear, I was hoping there would be a way someone could check out the samples and use them without having to do manual configuration, like importing modules. But maybe that simple solution would be the best.

[redbrogdon]

@blasten @xster, what do y'all think? If we need to reorganize some things in the samples, that's fine by me.

[xster]

Does the .iml files need to be in the .android directory or could it be at the module root? The prior art being that in co-editing mode, the IDE already operates against the entire module rather than just the .android directory for Dart editing.

In general, it'll continue to be the case that we dynamically generate the .android/.ios folders and they won't be checked in. If it can't be ready to go on checkout, could the plugin reference the same source of truth as the framework does for checking whether it's a Flutter module: we look at the pubspec.yaml and see if it has a flutter: module: key.

So in my mind:

• Best case scenario, we check in the .iml files and they're outside the .android folder
• Otherwise, if we try to import from AS, could it run flutter pub get automatically if .android is not present?
• Otherwise, we can update the documentation to say, run flutter pub get in the module first, then use it in AS.

[blasten]

I like the idea of checking for flutter: module in pubspec.yaml and if it's present, could the IDE run flutter pub get?

[stevemessick]

I'm not an expert on *.iml files so I don't know if that particular one could be moved to the root of the module.

However, I don't think we can check in the *.iml file. It has lots of version dependencies that could change when Flutter or Android is updated. Actually, I think it needs to be regenerated after an update of either.

With some additional work, I think the second suggestion @xster made could be implemented. I'm not sure how the flutter pub get would work with the module import yet, but there's no technical issue stopping it that I know of. I'll add this to Q2. @devoncarew for planning.

Unfortunately, I think there is a bug in the module import code in Android Studio that makes re-import break. That needs to get fixed (Q2 again). For now, @redbrogdon it would be best if the samples we checked in without the mods made by the importer. That way we can tell people to do flutter pub get then import the module into the Android app. I'll get on that bug soon, but it will be next week at the earliest, meaning the fix will be in the release at the end of April.

[redbrogdon]

For now, @redbrogdon it would be best if the samples we checked in without the mods made by the importer. That way we can tell people to do flutter pub get then import the module into the Android app.

Do you mean we should remove the flutter_module and flutter_module_using_plugin references from android_fullscreen and android_using_plugin, and instruct the user to manually add the modules back in?

I'm having some trouble keeping up here -- is the issue that the Android samples as they exist aren't working at all or that a future update to either Android or Flutter will break them if they've already been run by a user?

[stevemessick]

This is fixed with #4479 and is available in the latest point release.

The workflow is:

• Checkout the samples from github
• Do flutter pub get for each Flutter module
• Open the Android project and wait for two Gradle sync's to finish
• Everything should be ready; no need to import the module again