'debug' build type has default signing key, others do not [111118208]

Fixed

Bug

Status Update

No update yet.

Description

cc...@google.com

created issue #1

Jul 3, 2018 05:33PM

Having an unsigned, non-debuggable build is very useful for profiling, but when I try and run the release variant of a small test APK, I get the following error in the event log:

10:19 AM Error running 'app': The apk for your currently selected variant (app-profile.apk) is not signed. Please specify a signing configuration for this variant (profile).

This doesn't make sense to me, since I've in the past been able to run non-debuggable apps without signing, so I try and create a 'profile' variant which copies all the default settings from 'debug', but just sets debuggable -> false. Same error.

For some reason, I can edit the 'debug' build type to run debuggable, but not any other build type.

Build: 3.2 Beta 2, AI-181.5281.24.32.4860949, 201806252233, AI-181.5281.24.32.4860949, JRE 1.8.0_152-release-1136-b04x64 JetBrains s.r.o, OS Linux(amd64) v4.9.0-6-amd64 unknown, screens 2560x1600, 1920x1200Android Gradle Plugin: 3.3.0-alpha01Gradle: 4.8NDK: from local.properties: 15.0.4075724; latest from SDK: 15.0.4075724; LLDB: pinned revision 3.1 not found; latest from SDK: (package not found); CMake: from local.properties: (not specified); latest from SDK: /usr/local/google/sdk/cmake/3.6.3155560/bin/cmake -version/usr/local/google/sdk/cmake/3.6.3155560/bin/cmake: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory; from PATH: (not found); IMPORTANT: Please read

https://developer.android.com/studio/report-bugs.html carefully and supply all required information.

Comments

cc...@google.com <cc...@google.com> #2Oct 1, 2018 07:43PM

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

le...@google.com <le...@google.com> #3Oct 1, 2018 09:25PM

Assigned to rp...@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.

uc...@google.com <uc...@google.com> Mar 13, 2020 09:03PM

Reassigned to an...@google.com.

es...@google.com <es...@google.com> #4Apr 27, 2020 10:32PM

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"

cc...@google.com <cc...@google.com> #5Apr 28, 2020 02:52PM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

es...@google.com <es...@google.com> #6Apr 28, 2020 06:40PM

+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

cc...@google.com <cc...@google.com> #7Apr 28, 2020 06:58PM

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

je...@google.com <je...@google.com> May 4, 2020 04:21PM

Reassigned to cm...@google.com.

cm...@google.com <cm...@google.com> #8May 7, 2020 12:20PM

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

cm...@google.com <cm...@google.com> May 7, 2020 03:40PM

Accepted by cm...@google.com.

cm...@google.com <cm...@google.com> #9May 12, 2020 11:51AM

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.

je...@gmail.com <je...@gmail.com> #10Aug 24, 2021 07:22AM

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!

cc...@google.com <cc...@google.com> #11Nov 8, 2021 10:27PM

@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

cc...@google.com <cc...@google.com> Nov 17, 2021 09:01PM

Assigned to je...@google.com.

lu...@google.com <lu...@google.com> #12Jan 10, 2022 01:19PM

Hey @

comment#10

, do you have any news to share?

Android 13 is out today and we still have no patch unlike what you said a month ago

yi...@google.com <yi...@google.com> #13Feb 15, 2022 01:06AM

I have no words for this. Android 13 is labeled "stable" but the Wearable API just doesn't work. Can't this issue be given higher priority? If you want to push WearOS you need to make sure it works normally.

lu...@google.com <lu...@google.com> #14Feb 16, 2022 10:14AM

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.

yi...@google.com <yi...@google.com> #15Feb 16, 2022 08:29PM

comment#14

as much as I agree that is not a blocking bug, you need to understand that:
- 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

Wed Feb 16 2022 12:20:59 GMT-0800 (Pacific Standard Time).png

56 KB

View

Download

cm...@google.com <cm...@google.com> #16Feb 17, 2022 11:24AM

Reassigned to yi...@google.com.

Google will come through. They always do!

cm...@google.com <cm...@google.com> #17Feb 17, 2022 11:24AM

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.

yi...@google.com <yi...@google.com> #18Mar 21, 2022 06:55PM

Is there an update on by when can we expect a fix for this? We are blocked on the app release which is targeting Android 13. We can't roll out if it doesn't support wear os app.

Message last modified on Mar 21, 2022 06:55PM

di...@google.com <di...@google.com> #19Mar 23, 2022 02:15PM

Marked as fixed.

@Google Any updates here?

yi...@google.com <yi...@google.com> #20Mar 23, 2022 06:16PM

Status: Assigned (reopened)

I have to imagine this needs to be fixed, at least, for the launch of the Pixel Watch.

di...@google.com <di...@google.com> #21Mar 23, 2022 06:20PM

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.

yi...@google.com <yi...@google.com> #22Mar 23, 2022 06:52PM

Well, according to

https://issuetracker.google.com/issues/235538840#comment14 the fix must be in testing for over 5 weeks now. I guess it should be done soon™ /s.

so...@google.com <so...@google.com> #23Mar 24, 2022 12:45PM

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.

yi...@google.com <yi...@google.com> Apr 1, 2022 06:55PM