Status Update
Comments
am...@gmail.com <am...@gmail.com>
al...@gmail.com <al...@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.
al...@gmail.com <al...@gmail.com> #3
bt...@brandonthomson.com <bt...@brandonthomson.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
vl...@gmail.com <vl...@gmail.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
[Deleted User] <[Deleted User]> #8
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
pd...@gmail.com <pd...@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.
bt...@brandonthomson.com <bt...@brandonthomson.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!
bt...@brandonthomson.com <bt...@brandonthomson.com> #11
@
Thank you for the update @
ja...@fareclock.com <ja...@fareclock.com> #12
Android 13 is out today and we still have no patch unlike what you said a month ago
Description
URLs---concretely, where requests may have differing values of SERVER_NAME
(and HTTP_HOST). Currently, this is awkward to handle, for the following
reasons:
1. The app.yaml configuration does not allow requests to be processed
differently based on the server name. If I have any static handlers, for
example, they will appear under the same path on all hostnames aliased to
the app.
2. A script handler can easily look up SERVER_NAME (or HTTP_HOST) and
respond accordingly, but the existing frameworks don't facilitate this.
When you instantiate webapp.WSGIApplication, for example, you can only map
the path portion of the URL to different handler classes; you can't say
that
one.
(What I did was instantiate one webapp.WSGIApplication for each server
name, put them in a server-name-to-app-object dictionary, and dispatched
accordingly in main(). Not ideal, but at least it did the trick.)
I am using version 1.1.0 of the SDK on Linux.