Status Update
No update yet.
Comments
sg...@google.com
sg...@google.com
Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.
ph...@gmail.com
ra...@gmail.com
"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"
ap...@google.com
ap...@google.com
+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
ap...@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
ap...@google.com
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
ap...@google.com
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.
ap...@google.com
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!
Description
I started seeing
minifyReleaseWithR8task failure of my Compose project. It fails with some random project library jar, e.g.If I exclude this library from proguard, it'll fail with some next library - it can be both Compose one or any other, looks like message is unrelated to the problem.
By commenting code in the project, I've found out that I can fix the build by replacing one of
@StringRes param: Intin composable function withparam: String. But I still not sure if that's the root case.When trying to reproduce it in a sample project, I was able to reproduce it with even simpler code, that doesn't include int parameter. If I switch from compose-material to compose-material3, it builds fine.
MRE with dependencies is attached.