[AGP] Add generated source directory to IDE model (Variant API) [232805583]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

May 17, 2022 10:51AM

The new Variant API SourceDirectoriesImpl.addGeneratedSourceDirectory() allows to add a custom task generating source files that need to be compiled within the build process, but does not add the generated source directory to the IDE model in TaskProviderBasedDirectoryEntryImpl.

It is used in replacement of the old API BaseVariantImpl.registerJavaGeneratingTask() that automatically added the generated source directories to the IDE model.

It seems to me that the old behavior should be maintained, i.e., either:

set shouldBeAddedToIdeModel to true by default in the constructor of TaskProviderBasedDirectoryEntryImpl,
pass shouldBeAddedToIdeModel = true when creating TaskProviderBasedDirectoryEntryImpl in addGeneratedSourceDirectory,
add an optional argument to addGeneratedSourceDirectory for letting the user set the desired value of shouldBeAddedToIdeModel.

Note that it should go the same way with SourceDirectoriesImpl.addStaticSourceDirectory().

Also, I would personally not set the path of the output directory here if it has already been set by the user before calling addGeneratedSourceDirectory, since this overwriting is not documented and not obvious to the user. Or similarly to shouldBeAddedToIdeModel, this behavior (setting or not the output directory) could be controlled through an optional argument to addGeneratedSourceDirectory.

Please consider this other issue too that might be relevant as well (I did not try to reproduce it), it apppears not only in TaskProviderBasedDirectoryEntryImpl but also in ProviderBasedDirectoryEntryImpl.

Studio Build: #AI-213.7172.25.2211.8571212 (Android Studio Electric Eel | 2022.1.1 Canary 2)

Version of Gradle Plugin: 7.4.0-alpha02

Version of Gradle: 7.5-rc-1

Version of Java: 1.8

OS: Ubuntu 18.04

Comments

mk...@google.com <mk...@google.com> May 18, 2022 12:05PM

Assigned to an...@google.com.

je...@google.com <je...@google.com> #2May 24, 2022 08:02PM

Reassigned to al...@google.com.

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

al...@google.com <al...@google.com> Jun 3, 2022 03:53PM

Accepted by al...@google.com.

[Deleted User] <[Deleted User]> #3Jul 1, 2022 06:56PM

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

al...@google.com <al...@google.com> #4Jul 22, 2022 06:50PM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

al...@google.com <al...@google.com> #5Sep 16, 2022 11:13PM

Marked as fixed.

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

mi...@gmail.com <mi...@gmail.com> #6Sep 18, 2022 01:17PM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

cm...@google.com <cm...@google.com> #7Oct 10, 2022 04:54PM

Accepted by cm...@google.com.

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

cm...@google.com <cm...@google.com> #8Oct 12, 2022 03:03PM

Marked as fixed.

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

fr...@gmail.com <fr...@gmail.com> #9Oct 13, 2022 03:50PM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.