IssueTracker

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

+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

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

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

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.

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!

@comment#9 The Play Store will eventually require targeting API 33, then 34, etc, so accepting this regression in a customer release would be a time ticking bomb for Wear OS apps.

Thank you for the update @comment#10

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 Compatibility framework to toggle on/off the changes individually for isolated testing.

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.

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 https://android-developers.googleblog.com/2016/04/deprecation-of-bindlistener.html).

Appreciate all the feedback and patience.

Hey @comment#23 I can confirm the fix doesn't work. Tested on Pixel 6 Pro running Android 13 and a Pixel Watch running WearOS 3.5, things are working great if my app targets API 32 but doesn't when targetting API 33 using com.google.android.gms:play-services-wearable:18.0.0.

After 4 months of testing, it looks like it's broken.

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

Can you share the configuration code you have for the affected service from your AndroidManifest.xml file?

Sure thing, you can find them both in the commit that rolls back to targetting API 32: https://github.com/benoitletondor/PixelMinimalWatchFace/commit/604bdc2b640431a1216653c65f3bb86feda9a124

Sorry, wrong link:

• https://github.com/benoitletondor/PixelMinimalWatchFace/blob/release/2.2.0/android/companionapp/src/main/AndroidManifest.xml
• https://github.com/benoitletondor/PixelMinimalWatchFace/blob/release/2.2.0/android/watchface/src/main/AndroidManifest.xml

I don't think it's that, it was installed from PlayStore so it's a release one built from command line with a version bump

Maybe there was something wrong but all I did between this build and the new one is roll back to targeting API 32 and things worked immediately so it's strange to me.

As a reminder the fix require an update to Play Services on the device too.

Which Play Services version is supposed to fix it? We might add a check using PackageManager APIs to direct users to perform the update.

Have you taken into account the situation of Chinese devices? It's hard for them to upgrade the Play Service and there are no official solutions about this issue.

Issue is not yet solved, as we face the exact same problem still.

• Using targetSdk=31 and com.google.android.gms:play-services-wearable:18.1.0: OK
• Using targetSdk=33 and com.google.android.gms:play-services-wearable:18.1.0: NOT OK

When using targetSdk 33, messages are no longer sent from the wearable to the phone (e.g. WearableListenerService.onMessageReceived()) is no longer called.

You do not have the Arabic language. I am not fluent in English

1.1.5.2.5.2.5.1.5.4.4.2

No longer addressing technical debt would seem to imply sunsetting Android as far as Google is concerned. I suppose iOS is here to stay, and HarmonyOS will likely be a relevant player in the global market.

hypocrisy is rife...

Here is just a single issue were Google tells ALL developers worldwide to change/add-to their code because Google says-so: Edge-to-edge shouldn't be enable in Target SDK 35 App

I cannot be bothered listing the many-many-many areas where things became "deprecated/replaced" instead of "fixed". i.e. again: all developers to dump certain code and start with an entirely new approach.

I'm sure other people can add similar issues....

Thanks #46 but I'm already contributing to those repos and toolings. In fact, I'd be more than happy to mentor you if you ever want to try doing open source seeing that rwmobi Github profile has zero contributions. Just let me know, ya?

I also wish junit5 was supported for Android development. However I understand the Android team doesn't have infinite capacity. They can't do everything we want. What they said is simply that the upfront effort to support junit5 and than maintain it is too big for the returned value compared to doing something else that is more important for the community.

It is also quite ridiculous to suggest they fork some community effort. Google, like any big company, has very strict standard with code style and quality, they cannot just take a 3rd party software and fork it.

We are developers, 90% of our job is to chose between trade-offs. You should get this is a trade off and stop with the unreasonable requests. I'm glad they finally answered this ticket even if the outcome is not what I was hoping for.

Be thankful Google Android isn't ignoring you all, they are people, they really thought about this and they were forced to say no because at the end of the day the amount of work their team can deliver is finite.

they cannot just take a 3rd party software and fork it.

Robolectric was used to be a community open source project and they merged it into AndroidJUnit4. Dagger is also forked from Square. We have history in the past where taking over open source project has been successful. And Google has recently started embracing open source projects as well, such as deprecating Volley in favor of Retrofit. I don't think code style and quality matters. I do appreciate Google giving us an answer though even though it's not what we want to hear.