Status Update
Comments
xa...@gmail.com <xa...@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.
ce...@gmail.com <ce...@gmail.com> #3
[Deleted User] <[Deleted User]> #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"
xa...@gmail.com <xa...@gmail.com> #5
ce...@gmail.com <ce...@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
pe...@google.com <pe...@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
mr...@gmail.com <mr...@gmail.com> #8
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
[Deleted User] <[Deleted User]> #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!
[Deleted User] <[Deleted User]> #11
@
Thank you for the update @
ce...@gmail.com <ce...@gmail.com> #12
Android 13 is out today and we still have no patch unlike what you said a month ago
[Deleted User] <[Deleted User]> #13
ps...@gmail.com <ps...@gmail.com> #14
This issues has been already given high priority (updated external priority on this bug to reflect internal status). The fix is on the way and going through the final rounds of testing, so the roll out is slated to next couple of weeks.
To reiterate what have been mentioned earlier on this bug: this issue affects only apps targeting Android 13, so the apps won't break unless you bump targetSDK
version to 33
. In case if you want to start working on app compatibility for Android 13 behaviour changes, you could use
ku...@gmail.com <ku...@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
pe...@gmail.com <pe...@gmail.com> #16
ph...@gmail.com <ph...@gmail.com> #17
That must be some really intense testing as we are 10 days later and still nothing on sight. I don't want to be a P2 issue if that's what a P1 is.
pe...@gmail.com <pe...@gmail.com> #18
sh...@gmail.com <sh...@gmail.com> #19
gu...@gmail.com <gu...@gmail.com> #20
th...@gmail.com <th...@gmail.com> #21
My bet is that Google still targets API 32 (or even lower) internally so they don't care and didn't even saw the issue before our report.
la...@gmail.com <la...@gmail.com> #22
js...@google.com <js...@google.com>
br...@gmail.com <br...@gmail.com> #23
This issue is fixed. The fix has been rolled out via GMSCore and will also require using the latest com.google.android.gms:play-services-wearable:18.0.0
release.
Note that you don’t need to add BIND_LISTENER
manually, it has been deprecated for a long time and it continue to remain so (read more at
Appreciate all the feedback and patience.
[Deleted User] <[Deleted User]> #24
la...@gmail.com <la...@gmail.com> #25
Hey @com.google.android.gms:play-services-wearable:18.0.0
.
After 4 months of testing, it looks like it's broken.
[Deleted User] <[Deleted User]> #26
rm...@google.com <rm...@google.com> #27
Well that's possible but I've tested things carefully and targetting API 32 immediately fixes the behavior so I'm confident this is the root cause of the issue
Description
blacklist:
- rate-limit: 1000
rate-limit-period: 1m
You already track the ip addresses and request counts in last M minutes. (Admin console/Administration/Blacklist page). Just automatically block the ips who reached the rate-limit.