Status Update
No update yet.
Comments
so...@google.com
Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.
sh...@google.com
fa...@google.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"
do...@google.com
ph...@battelleecology.org
+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
r....@elderbyte.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
jo...@edf-re.io
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
ec...@gmail.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.
ku...@google.com
ku...@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!
sj...@battelleecology.org
@
Thank you for the update @
bo...@worksome.com
Android 13 is out today and we still have no patch unlike what you said a month ago
br...@qargo.com
va...@google.com
su...@google.com
[Deleted User] <[Deleted User]>
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
Description
We would like either an explicit replace/modify permission or the delete permission to be removed from the requirements to replace an object in a GCS bucket with versioning enabled. "With versioning enabled, it's easier to argue that object inserts become pure inserts. Alas, we never changed the existing behavior (aka removing the storage.objects.delete permission check)." This would allow us to not have to grant the delete permission to a Service Account or user and properly provision a lesser permission.
How this might work:
Similar to AWS S3 buckets, where the replace/modify action is different than the delete action.
If applicable, reasons why alternative solutions are not sufficient:
We feel that delete is too great of a permission for Service Accounts, even on versioned buckets, and would prefer it only be able to modify/create, similar to other file systems.
Other information (workarounds you have tried, documentation consulted, etc):
Documentation detailing the required permission: