exFAT file modification times wrong for files created on Mac OS [124356537]

Infeasible

Bug

[AOSP] assigned

Status Update

No update yet.

Description

sb...@gmail.com

created issue #1

Feb 13, 2019 06:38PM

(Trying to report a bug, and hoping this is an appropriate forum)

The modification times of files created by Mac OS on exFAT drives are interpreted incorrectly by Android on Samsung devices.

Specifically, a file written to an exFAT drive on Mac OS reports its times correctly on Mac OS, Windows, and Linux, but is skewed 16 hours in the future on Samsung Android devices alone. Files times are correct for files created by Samsung Android on exFAT devices and used elsewhere, but files created by Mac OS (only) have incorrect times on Samsung Android (only). This hampers interoperability of exFAT drives on these mobile devices for Mac OS users, and impacts tools like incremental-backup programs.

For more details on this bug, including related screenshots and test details, please see this page:

https://learning-python.com/mergeall-android-scripts/_README.html#toc22

This bug was verified to exist in Android Nougat and Oreo, and on Samsung J7, S8+, and Note 9 devices. It occurs only for files written by Mac OS (El Capitan through High Sierra). Files written to exFAT drives on Windows (7 through 10) have correct times on Samsung Android, and files written by Mac OS have correct times outside Android.

To recreate the bug: save a file to an exFAT USB drive on Mac OS, and inspect its modification time on any of the Android versions and devices noted; it will be incorrect on the latter. The bug's status on Android Pie is unknown.

Comments

ad...@google.com <ad...@google.com> #2Feb 14, 2019 10:40AM

Assigned to ad...@google.com.

Thanks for filling this, HiltViewModelFactory wraps around a SavedStateViewModelFactory which is also the default one for non Hilt injected Fragments and Activities, it seems there is some key conflicts, I'll investigate and comer back with more info soon, thanks for the sample app!

sb...@gmail.com <sb...@gmail.com> #3Feb 14, 2019 05:58PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d76172ec45a778efe5f46b6ad1a50ae24241d14d
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Jun 16 14:50:23 2020

Avoid SavedStateHandle key conflict in HiltViewModelFactory.

When delegating to the SavedStateViewModelFactory to create
ViewModels that are not Hilt injected, the factory will attempt
to retrieve a SavedStateHandler using a controller with the same
key as the SavedStateHandle passed into the abstract create() method
of AbstractSavedStateViewModelFactory for which the
HiltViewModelFactory implements. Therefore causing a key conflict.

In this change we avoid the key conflict collision by prefixing the
before delegating to SavedStateViewModelFactory. Since ViewModels
will be either create by one or the other factory, it is safe to
mangle the key. Meanwhile, even though the key is also used to
add a tag to the ViewModel for cleanup, the tag is only added
if the key used is not present. When SavedStateViewModelFactory
tags the ViewModel and then a second time in once
AbstractSavedStateViewModelFactory#create() returns, the tag
is not overridden (lucky us).

This fixes a bug when mixing vanilla ViewModels and Hilt injected
ones.

Bug: 158737069
Test: ViewModelApp Integration Tests
Change-Id: I86ae254c2f26795c900317d42041319fd279e545

M buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
M hilt/hilt-lifecycle-viewmodel/src/main/java/androidx/hilt/lifecycle/HiltViewModelFactory.java
M hilt/integration-tests/viewmodelapp/build.gradle
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/ActivityInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/BaseActivityInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/BaseFragmentInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/Bindings.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/FragmentInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/MyViewModels.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/TestRunner.kt
A hilt/integration-tests/viewmodelapp/src/debug/AndroidManifest.xml

https://android-review.googlesource.com/1339862

ad...@google.com <ad...@google.com> #4Feb 15, 2019 12:24PM

A fix for this will be available in alpha02

js...@google.com <js...@google.com> #5Feb 15, 2019 04:32PM

Status: Won't Fix (Infeasible)

This is feedback for a specific OEM device, which we can't support from AOSP; instead, please reach out to your OEM directly. (Note that AOSP does not contain an exFAT implementation.)

sb...@gmail.com <sb...@gmail.com> #6Feb 15, 2019 07:50PM

Understood; could you please suggest a Samsung site to which this could be forwarded? The site I've already tried does not sound very promising, and my interest here is in alerting the OEM of an issue that should really be addressed in its Android-based products.

sb...@gmail.com <sb...@gmail.com> #7Feb 27, 2019 11:30PM

An update for anyone stumbling onto this post in the future: this bug was also reported on the Samsung Developers forum and the Samsung+ app (the US equivalent of Samsung Members). It was also later discovered that Samsung Android devices sometimes _write_ files to exFAT drives with incorrect modification times that show up as -16 hours off on both Mac OS and Windows.

I.e., it's not just reads, and not just Mac OS content. This bug may stem from the fact that Android timestamps were broken in general until Oreo, but really should be fixed today. See the original post's link above for more details.

Issue 124356537