It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@christopherfujino
Can you find someone developer help to review this pull request for this issue?
Thanks.

cc @stuartmorgan does this look like the right change?

I'm not familiar with the internal build setup of Android plugins; @blasten would be a better reviewer.

This needs to be fixed in the template file. The fix is:

https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/module/android/host_app_common/app.tmpl/build.gradle.tmpl#L33

should have a section similar to:

flutter/packages/flutter_tools/templates/app_shared/android-java.tmpl/build.gradle

Lines 20 to 22 in ad3fe21

	subprojects {
	project.buildDir = "${rootProject.buildDir}/${project.name}"
	}

I have changed the plugin's output directory to ${rootProject.buildDir}/${pluginName} by changes for PR-94645., you can review this pr again.
Thanks @blasten

can we add the subproject logic below this line https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/module/android/host_app_common/app.tmpl/build.gradle.tmpl#L33?

The reason is that the file you are changing is also used for other case where this change may or may not make sense.

can we add the subproject logic below this line https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/module/android/host_app_common/app.tmpl/build.gradle.tmpl#L33?

The reason is that the file you are changing is also used for other case where this change may or may not make sense.

In some case, the host gradle project may dependent the plugin's native module directly. and the templete may not work for this case.

such as:
We add flutter_aliplayer to flutter project's pubspec.yaml. and sync the host project's gradle file. and then we will see a native module named :flutter_aliplayer appear in module list, and then we can let host project dependent this module(sometime, this can aviod some .so library conflict).

@blasten
Is the ${flutterModule}/build/host/${pluginName} was a better directory I could use for this?

Hi~ @blasten
The forked repo has add access for you. please have a look at this pull request.
Thanks very much.

Gold has detected about 6 new digest(s) on patchset 4.
View them at https://flutter-gold.skia.org/cl/github/94645

@blasten can you take a look at this PR?

@blasten friendly ping
@chunfengyao to get the customer_testing-linux CI check to pass, you will have to rebase (not merge) upstream master.

@blasten friendly ping @chunfengyao to get the customer_testing-linux CI check to pass, you will have to rebase (not merge) upstream master.

thanks for tips, I rebased the branch with latest master.

For the test, https://github.com/flutter/flutter/blob/master/packages/flutter_tools/test/integration.shard/android_plugin_compilesdkversion_mismatch_test.dart is an example of how Gradle intergrations are currently tested.

For the test, https://github.com/flutter/flutter/blob/master/packages/flutter_tools/test/integration.shard/android_plugin_compilesdkversion_mismatch_test.dart is an example of how Gradle intergrations are currently tested.

@blasten I have ran the test , and got no error.

/Volumes/Storage/AS_WS/flutter_issue_handle/bin/cache/dart-sdk/bin/dart run test -r json /Volumes/Storage/AS_WS/flutter_issue_handle/packages/flutter_tools/test/integration.shard/android_plugin_compilesdkversion_mismatch_test.dart
Testing started at 11:57 ...

Process finished with exit code 0

@GaryQian should review this as well.

I clicked the re-request review button, and github removed @GaryQian . @stuartmorgan maybe you can request review again. Thanks.

@stuartmorgan So in Gradle, the : indicates that something is a subproject of something else. :blah represents a root project, while hello:blah represents a project hello with a subproject blah. Since the code here is specifically a subproject of the root project, the .name property should not return a "path" style value with colons. Instead, subprojects of subprojects are to be found in the .subprojects property. Thus, we should not expect to find colons in subproject.name and the colon parsing/replacement is not necessary.

Thanks for that explanation!

@stuartmorgan So in Gradle, the : indicates that something is a subproject of something else. :blah represents a root project, while hello:blah represents a project hello with a subproject blah. Since the code here is specifically a subproject of the root project, the .name property should not return a "path" style value with colons. Instead, subprojects of subprojects are to be found in the .subprojects property. Thus, we should not expect to find colons in subproject.name and the colon parsing/replacement is not necessary.

It has been discussed at the beginning of this PR.
But from the docs provided by Gradle, It seems that colons was used in gradle task's name to split project's name and action. (I'm not familiar with the detail of gradle task.)
And I don't remember whether the colon was before subproject's name acturally , or the first version of this PR uses the task's name as the plugin name?
But CI check passed when I removed the colons replacement.

Thanks for everyone who helped this PR!