Assigned
Status Update
No update yet.
Comments
ab...@google.com
Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.
sk...@google.com
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.
an...@google.com
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"
"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"
me...@google.com
Experiencing the same issues, please see my other report for any useful logs:
https://issuetracker.google.com/issues/235673375
jc...@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
si...@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
ab...@google.com
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
em...@paypal.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.
Description
This will create a feature request which anybody can view and comment on.
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
The customer is blocked by this limitation, because a HMAC-256 key provided to us by a 3rd party is longer than 32 Bytes and wants to allow importing symmetric HMAC-256 keys longer than 32 Bytes.
The google documentation states that [1]: Symmetric keys for signing (MAC keys) must have length equal to the output length of the cryptographic hash function being used (e.g. HMAC-SHA256 keys must have a length of 32 bytes), and must not be encoded. If your key is hex-encoded or base-64 encoded, you must decode it before attempting to import it.
[1]https://cloud.google.com/kms/docs/formatting-keys-for-import#supported_key_formats
How this might work:
The KMS allows the importing of HMAC-256 keys longer than 32 Bytes.
If applicable, reasons why alternative solutions are not sufficient:
The customer is currently storing the key in a secret manager but wants to move it to KMS( due to security concerns ), but is not able to do so because the 3rd party key is longer than 32 bytes.
Other information (workarounds you have tried, documentation consulted, etc):
Read the following documentation:
[1]https://cloud.google.com/kms/docs/key-import#key_import_flow
[2]https://cloud.google.com/kms/docs/importing-a-key#request_import
[3]https://cloud.google.com/kms/docs/formatting-keys-for-import#check_symmetric_key
The length for an SHA-256 HMAC key is 32 bytes. A key longer than 32 bytes does not significantly increase the function strength unless the randomness of the key is considered weak. A key longer than 64 bytes will be hashed before it is used. ):