Even if DateTimeOriginal is set in the image's Exif, the MediaStore#DATE_TAKEN column returns null [385996093]

Assigned

Bug

[AOSP] assigned

Status Update

No update yet.

Description

io...@mixi.co.jp

created issue #1

Dec 25, 2024 10:04AM

Environment:

Android Studio Build: Android Studio Ladybug | 2024.1.2 Patch 2
SDK versions
- compileSdk: 35
- targetSdk: 34
Kotlin version: 1.9.24
Devices: Pixel 6a, Pixel Fold (It may occur on other devices as well.)
OS version: 14

Issue Summary:

I tried to retrieve an image with DateTimeOriginal set in the Exif from the device via ContentResolver. When I used MediaStore#DATE_TAKEN to get the date taken, it returned null, so I couldn't retrieve the date. Upon further investigation, I found that I could retrieve the date taken by adding the Exif tag called SubSecDateTimeOriginal using Exiftool.

However, even after modifying the Exif so that MediaStore#DATE_TAKEN could correctly retrieve the date taken and removing SubSecDateTimeOriginal, the date was still retrieved without any issues.

I'm not entirely sure, but I suspect that even if DateTimeOriginal is present in the Exif, MediaStore#DATE_TAKEN might not be able to retrieve the date taken depending on the combination of Exif tags, unless SubSecDateTimeOriginal is also present.

Ideally, MediaStore#DATE_TAKEN should be able to obtain the DateTimeOriginal value regardless of the combination of Exif tags. I would like to hear your opinions.

Steps to Reproduce or Code Sample to Reproduce:

I would like to attach an image where the date taken is incorrect with MediaStore#DATE_TAKEN, but unfortunately, I don't have that image on hand right now. I will attach it as soon as I obtain it.

Comments

vi...@google.com <vi...@google.com> #2Dec 26, 2024 04:42AM

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

vi...@google.com <vi...@google.com> #3Jan 2, 2025 02:10PM

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.

io...@mixi.co.jp <io...@mixi.co.jp> #4Jan 9, 2025 01:47AM

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"

io...@mixi.co.jp <io...@mixi.co.jp> #5Jan 9, 2025 09:55AM

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

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

vi...@google.com <vi...@google.com> #6Jan 13, 2025 07:18PM

+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

io...@mixi.co.jp <io...@mixi.co.jp> #7Jan 17, 2025 03:34AM

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 <vi...@google.com> #8Jan 21, 2025 05:28AM

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

io...@mixi.co.jp <io...@mixi.co.jp> #9Jan 23, 2025 01:23AM

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.

vi...@google.com <vi...@google.com> #10Jan 26, 2025 05:59PM

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!