Status Update
Comments
dk...@sudo.ch <dk...@sudo.ch> #2
Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.
ka...@gmail.com <ka...@gmail.com> #3
ka...@gmail.com <ka...@gmail.com> #4
"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"
th...@gmail.com <th...@gmail.com> #5
ke...@gmail.com <ke...@gmail.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
ma...@gmail.com <ma...@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
ka...@gmail.com <ka...@gmail.com> #8
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
ka...@gmail.com <ka...@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.
ca...@gmail.com <ca...@gmail.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!
ha...@content-studios.com <ha...@content-studios.com> #11
@
Thank you for the update @
de...@gmail.com <de...@gmail.com> #12
Android 13 is out today and we still have no patch unlike what you said a month ago
kr...@gmail.com <kr...@gmail.com> #13
de...@gmail.com <de...@gmail.com> #14
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
ev...@gmail.com <ev...@gmail.com> #15
- 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
de...@gmail.com <de...@gmail.com> #16
de...@gmail.com <de...@gmail.com> #17
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.
de...@gmail.com <de...@gmail.com> #18
ev...@gmail.com <ev...@gmail.com> #19
ev...@gmail.com <ev...@gmail.com> #20
de...@gmail.com <de...@gmail.com> #21
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.
de...@gmail.com <de...@gmail.com> #22
ev...@gmail.com <ev...@gmail.com> #23
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
Appreciate all the feedback and patience.
de...@gmail.com <de...@gmail.com> #24
ev...@gmail.com <ev...@gmail.com> #25
Hey @com.google.android.gms:play-services-wearable:18.0.0
.
After 4 months of testing, it looks like it's broken.
ev...@gmail.com <ev...@gmail.com> #26
de...@gmail.com <de...@gmail.com> #27
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
ev...@gmail.com <ev...@gmail.com> #28
Can you share the configuration code you have for the affected service from your AndroidManifest.xml
file?
ed...@gmail.com <ed...@gmail.com> #30
ev...@gmail.com <ev...@gmail.com> #31
Are you 100% sure that the apk deployed was not an old one with the
old library version for example?
Since there's been some issues with that in past Android Studio versions
and AGP, and since I'm not sure if it's fully fixed and which versions did,
I'd try to run the clean Gradle task, and then run the install task from
command line, and also make sure you're not trying the wrong
buildType/variant.
Please keep us updated.
On Sun, Oct 23, 2022 at 3:56 PM <buganizer-system@google.com> wrote:
pa...@gmail.com <pa...@gmail.com> #32
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.
ev...@gmail.com <ev...@gmail.com> #33
As a reminder the fix require an update to Play Services on the device too.
pa...@gmail.com <pa...@gmail.com> #34
Indeed I can see PlayServices aren't updated on my device, like on a lot of Android devices right now auto-update of apps is broken.
I'll try again with up to date services and I'll let you know.
But that means it's far from production ready as we can't expect all of our users to be up to date right now so I'm glad I rollbacked to API 32 for now.
ev...@gmail.com <ev...@gmail.com> #35
Which Play Services version is supposed to fix it? We might add a check using PackageManager APIs to direct users to perform the update.
de...@gmail.com <de...@gmail.com> #36
de...@gmail.com <de...@gmail.com> #37
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.
ev...@gmail.com <ev...@gmail.com> #38
de...@gmail.com <de...@gmail.com> #39
=======
"Status
You won't be able to release app updates (11 days away)
Date sent
Aug 10, 2023
Deadline
Aug 30, 2023
Violation
App must target Android 13 (API level 33) or higher"
ev...@gmail.com <ev...@gmail.com> #40
Issue is not yet solved, as we face the exact same problem still.
- Using
targetSdk=31
andcom.google.android.gms:play-services-wearable:18.1.0
: OK - Using
targetSdk=33
andcom.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.
an...@gmx.at <an...@gmx.at> #41
com.google.android.gms:play-services-wearable:18.1.0
di...@gmail.com <di...@gmail.com> #42
di...@gmail.com <di...@gmail.com> #43
You do not have the Arabic language. I am not fluent in English
ap...@google.com <ap...@google.com>
mi...@gmail.com <mi...@gmail.com> #44
ar...@gmail.com <ar...@gmail.com> #45
1.1.5.2.5.2.5.1.5.4.4.2
pr...@google.com <pr...@google.com> #46
de...@gmail.com <de...@gmail.com> #47
Mac OS X 10.7.2
Eclipse Helios
Google App Engine 1.6.1
Java 1.6.0_29
Mojarra 2.0.6
I can run in this configuration without a patched WebConfiguration.java file.
In the WebConfiguration.java file (used during the initialization portion of the JSF 2.0 framework), the following method is used as an attempt to "determine" whether or not JNDI entries can be processed.
private boolean canProcessJndiEntries() {
try {
Util.getCurrentLoader(this).loadClass("javax.naming.InitialContext");
} catch (Exception e) {
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.fine(
"javax.naming is unavailable. JNDI entries related to Mojarra configuration will not be processed.");
}
return false;
}
return true;
}
This method, when invoked, returns true.
The following is the contents of the processJndiEntries(String) method with my comments interspersed.
/**
* <p>Process all JNDI entries.</p>
* @param contextName the context name
*/
private void processJndiEntries(String contextName) {
Context initialContext = null;
try {
///***** DB Comment Begin
///* In the dev server at least, the initialContext is instantiated.
///***** DB Comment End
initialContext = new InitialContext();
} catch (NamingException ne) {
if (LOGGER.isLoggable(Level.WARNING)) {
LOGGER.log(Level.WARNING, ne.toString(), ne);
}
}
if (initialContext != null) {
// process environment entries
for (WebEnvironmentEntry entry : WebEnvironmentEntry.values()) {
///***** DB Comment Begin
///* WebEnvironmentEntry.values() returns the WebEnvironmentEntry objects with the following names:
///* java:comp/env/ClientStateSavingPassword
///* java:comp/env/jsf/ProjectStage
///***** DB Comment End
String entryName = entry.getQualifiedName();
String value = null;
try {
value = (String) initialContext.lookup(entryName);
///***** DB Comment Begin
///* The following exception is thrown here:
///* javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
///***** DB Comment End
} catch (NamingException root) {
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.fine(root.toString());
}
}
if (value != null) {
///***** DB Comment Begin
///* As value is null, nothing happens in this portion of the loop
///***** DB Comment End
if (LOGGER.isLoggable(Level.INFO)) {
// special logic for ClientStateSavingPassword
if (!entry
.equals(WebEnvironmentEntry.ClientStateSavingPassword)) {
if (LOGGER
.isLoggable(loggingLevel)) {
LOGGER.log(loggingLevel,
"jsf.config.webconfig.enventryinfo",
new Object[]{contextName,
entryName,
value});
}
} else {
if (LOGGER
.isLoggable(loggingLevel)) {
LOGGER.log(loggingLevel,
"jsf.config.webconfig.enventry.clientencrypt",
contextName);
}
}
}
envEntries.put(entry, value);
}
}
}
}
de...@gmail.com <de...@gmail.com> #48
de...@gmail.com <de...@gmail.com> #49
de...@gmail.com <de...@gmail.com> #50
The doLoggingActions() method in changed from the following in 2.0.4:
public void doLoggingActions() {
if (deferredLoggingActions != null) {
for (DeferredLoggingAction loggingAction : deferredLoggingActions) {
loggingAction.log();
}
}
}
to the following in the 2.0.6 code.
public void doLoggingActions() {
if (deferredLoggingActions != null) {
for (DeferredLoggingAction loggingAction : deferredLoggingActions) {
loggingAction.log();
}
}
// add the HttpMethodRestrictionPhaseListener if the parameter is enabled.
boolean enabled = this.isOptionEnabled(BooleanWebContextInitParameter.EnableHttpMethodRestrictionPhaseListener);
if (enabled) {
LifecycleFactory factory = (LifecycleFactory) FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Iterator<String> ids = factory.getLifecycleIds();
PhaseListener listener = null;
Lifecycle cur;
while (ids.hasNext()) {
cur = factory.getLifecycle(ids.next());
boolean foundExistingListenerInstance = false;
for (PhaseListener curListener : cur.getPhaseListeners()) {
if (curListener instanceof HttpMethodRestrictionsPhaseListener) {
foundExistingListenerInstance = true;
break;
}
}
if (!foundExistingListenerInstance) {
if (null == listener) {
listener = new HttpMethodRestrictionsPhaseListener();
}
cur.addPhaseListener(listener);
}
}
}
}
The following lines were added to the 2.0.6 version as part of the body of the BooleanWebContextInitParameter() method.
EnableHttpMethodRestrictionPhaseListener(
"com.sun.faces.ENABLE_HTTP_METHOD_RESTRICTION_PHASE_LISTENER",
false
),
Description