Status Update
Comments
li...@gmail.com <li...@gmail.com> #2
Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.
ch...@google.com <ch...@google.com>
li...@gmail.com <li...@gmail.com> #3
je...@google.com <je...@google.com>
sp...@google.com <sp...@google.com> #4
"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"
ra...@google.com <ra...@google.com>
pa...@google.com <pa...@google.com>
pa...@google.com <pa...@google.com> #5
li...@gmail.com <li...@gmail.com> #6
+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
pa...@google.com <pa...@google.com> #7
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
pa...@google.com <pa...@google.com> #8
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
li...@gmail.com <li...@gmail.com> #9
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.
sa...@google.com <sa...@google.com> #10
As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!
sa...@google.com <sa...@google.com> #11
@
Thank you for the update @
li...@gmail.com <li...@gmail.com> #12
Android 13 is out today and we still have no patch unlike what you said a month ago
pa...@google.com <pa...@google.com>
pa...@google.com <pa...@google.com> #13
li...@gmail.com <li...@gmail.com> #14
li...@gmail.com <li...@gmail.com> #15
- The report is 2 months old
- Google chose to release Android 13 with that bug
- There's no mention of this bug on the documentation so you can totally bump your targetSdk without noticing it
So thank you guys for working on this but it's still not a valid excuse for taking that long for such an important issue. Now that being said, let us know when a fix is available
Description
DESCRIBE THE ISSUE IN DETAIL:
STEPS TO REPRODUCE:
./gradlew :app:lintDebug
and observe 2 issues;./gradlew :lint-checks:test
and observe tests failing.It looks like
PartialResult#map
doesn't follow the contract in unit tests. It claims to returnLintMap
for the project in context, but under the certain condition it seems to be violated.The conditions require multimodule setup. A
library
module must put smth into itsLintMap
. Then, when theapp
module accesses its ownLintMap
for the first time it get a map prefilled with the data from thelibrary
module, instead of the fresh one.To demonstrate the issue I created the following setup:
:app
module and a:library
module;:app
module containsapp_color
color resource, while:library
module contains:library_color
;color
resource declaration within the module, puts into the partial results and then reports all colors found per module incheckPartialResults
method;If you run lint checks using the
./gradlew :app:lintDebug
command, you'll observe Lint correctly reportingapp_color
found in:app
andlibrary_color
found in:library
. However, if you run the unit tests, you'll observe that Lint also reports alibrary_color
found in the:app
.It looks like while scanning the
:app
module, the first access to partial results, causesLintCliClient
to create new instance of results and fill it with results of the dependent module (seeLintCliClient#getPartialResults
method). For some reason this is happening only in tests.The replacement of the
getPartialResult.map()
method call withgetPartialResult.mapFor(context.project)
method call successfully addresses the issue.There's still a chance, that my test is wrong. In this case, would be great to know in which way.
Studio Build: Chipmunk | 2021.2.1 Version of Gradle Plugin: 7.2.1, 7.4.0-alpha08 Version of Gradle: 7.4.2 OS: Mac OS Monteray 12.4