Status Update
No update yet.
Comments
vi...@google.com
Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.
ki...@linecorp.com
ki...@linecorp.com
"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"
vi...@google.com
ki...@linecorp.com
+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
ki...@linecorp.com
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
vi...@google.com
I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨
vi...@google.com Restricted+
vi...@google.com
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!
ki...@linecorp.com
@
Thank you for the update @
ki...@linecorp.com
Android 13 is out today and we still have no patch unlike what you said a month ago
ki...@linecorp.com
sa...@google.com
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
Description
Hello.
I am creating a PassThroughTranscoder using MediaExtractor and MediaMuxer inside the LINE app.
In MediaMuxer, the presentation time of the frame can only be received in order of increasing time.
However, the problem is that when I output sampleTime (presentation time) in Android's MediaExtractor, it is not displayed in order of increasing time.
As shown below, there are cases where a smaller time is output than the previously output time.
The time of the frame is determined to be a B/P Frame.
When I output the presentation time of the same video file with FFMpeg (ffprobe), it is output in order of increasing time, unlike MediaExtractor.
So I guess it is not a problem with the video file.
Do you have any ideas or ways to fix this bug?
Since I have to pass it to MediaMuxer, there is a problem with arranging all the information of the frame in memory.
I have attached a test video and a sample app.
Please help me.