Fixed
Status Update
No update yet.
Comments
vi...@google.com
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
What steps are needed to reproduce this issue? Frequency of occurrence?
Which Android build are you using? (e.g. OPP1.170223.012)
Which device did you use to reproduce this issue?
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:https://developer.android.com/studio/debug/bug-report#bugreportdevice
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the bug report and screenshot to google drive and share the folder to android-bugreport@google.com, then share the link here.
What steps are needed to reproduce this issue? Frequency of occurrence?
Which Android build are you using? (e.g. OPP1.170223.012)
Which device did you use to reproduce this issue?
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the bug report and screenshot to google drive and share the folder to android-bugreport@google.com, then share the link here.
ar...@komoot.de
Android version: T
Problem recurrence: Execute Antutu, and pay attention to the XML processing score
Phenomenon: replace the "name expected" in the KXmlParser.java file on the ssi side with a variable. After modification, the XML processing score of Angora Rabbit improved significantly.
Modify to: static final private String NAME_ EXPECTED = "name expected"; And use NAME_ EXPECTED for subsequent "name expected"
Thanks!
ma...@gmail.com
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
Description
I think I found a bug in the Wear OS Message Client messaging system.
It's either the Wear OS or the Play services library com.google.android.gms:play-services-wearable. Can't determine which component could be the root cause.
The Setup:
There is a Wear App and a Phone App that can communicate via the MessageClient API with each other. They share the same app id and rely on each other for a user's use case. Both apps use a WearableListenerService to get called on a new message and to get startup if not running yet. Each app can send a simple message to its companion app and receive an acknowledgment message from it too.
The Problem:
The app process on the wearable device does not start up immediately (on the first message) by a message has been sent from the phone app. Sending a second message let the wear app process startup and WearableListenerService can receive the message.
This only happens in what I call the initial void state. It's when both apps are not running (you can force kill the process to test this). Starting up the phone app and letting the user send a message won't result in receiving the message on the Wear app. Only on sending a second message, it works as expected. See the video in the GDrive.
I also observed the same behavior in that the Phone app does not start up immediately with a message from the Wear app. But this is harder to reproduce.
Devices I used to reproduce the issue:
- Google Pixel Watch (Wifi)
- Samsung S21 Ultra
A demonstration video and an example app project are here:
Thank you