IssueTracker

There's an undocumented (as far as I can tell) behavior change in Android 10 when using mode "w" with ParcelFileDescriptor.parseMode.

Android 9 and below

Using mode "w" and writing to a file that already exists truncates the file, completely overwriting it.

Android 10 and above

Using mode "w" and writing to a file that already exists no longer truncates the file being overwritten. This can result in a corrupt file if the new file is smaller than the old file.

Workaround for ParcelFileDescriptor.parseMode

In order to get the old behavior on Android 10+, the user simply needs to use mode "wt". This mode, and the other available modes, are listed in ParcelFileDescriptor.parseMode, however, their meanings are not documented there.

Fallout: ContentResolver.open*

The real issue resides in APIs that use ParcelFileDescriptor.parseMode under-the-hood, such as the various ContentResolver.open* APIs (in particular when using the SAF and file system URIs). There are two main issues:

1. ContentResolver.openOutputStream uses mode "w" by default. So anyone using this API unknowingly gets this behavior change on Android 10+.

2. The various ContentResolver.open* APIs either:

   a. Do not list any acceptable modes in their documentation.

   b. List only a subset of modes that ParcelFileDescriptor.parseMode lists.

   c. Refer to various ContentProvider.open* APIs, which also do (a) and (b) above.

   d. None of the ContentResolver.open* or ContentProvider.open* APIs list mode "wt" as an acceptable mode (despite it being listed by ParcelFileDescriptor.parseMode). Using mode "wt" with these APIs results in other issues (see Problems with mode "wt" section below).

Sample app to reproduce the issue

I've attached a sample app which demonstrates the issue. Please do the following:

1. Tap Save large file. This launches the SAF. Make sure you're in Downloads and tap Save. This will toast "Large file save complete" when the save has finished.

2. Tap Verify large file. This launches the SAF. Tap the file you saved in step 1. This should toast "Verified", meaning the file written in step 1 has the expected contents.

3. Tap Overwrite large file with small file. This launches the SAF. Tap the file you saved in step 1 (this is important), then tap Save. You should see a dialog saying "Overwrite file?", tap Ok. This will toast "Small file save complete" when the save has finished.

4. Tap Verify small file. This launches the SAF. Tap the file you saved in step 1 / 3. This will toast either "Verified", meaning the file written in step 3 has the expected contents, or "Small file corrupted", meaning it does not have the expected contents.

Result

Following the above steps on Android 9 and below results in step 4 showing "Verified".

Following the above steps on Android 10+ results in step 4 showing "Small file corrupted".

AOSP commit that caused this behavior change

This is the commit that caused the behavior change. You can see the previous logic in ParcelFileDescriptor.parseMode which equated mode "w" with mode "wt", both of which included MODE_TRUNCATE:

} else if ("w".equals(mode) || "wt".equals(mode)) {
    modeBits = ParcelFileDescriptor.MODE_WRITE_ONLY
            | ParcelFileDescriptor.MODE_CREATE
            | ParcelFileDescriptor.MODE_TRUNCATE;
}

This logic was moved to FileUtils.translateModeStringToPosix where mode "w" now only results in POSIX modes O_WRONLY | O_CREAT, dropping truncate. To include O_TRUNC, a "t" must exist in the mode.

Was this an intentional change?

While this seems to have been an intentional change, I'm not 100% sure. There is a test for mode "w" that specifically does not include MODE_TRUNCATE, however, for some reason it includes MODE_CREATE twice:

assertTranslate("w", O_WRONLY | O_CREAT,
        MODE_WRITE_ONLY | MODE_CREATE | MODE_CREATE);

It does make sense that there should be a way to open a file for writing without always truncating the existing file. However, I would not expect this to be the default behavior for ContentResolver.openOutputStream. The general use case when writing a file is completely replacing any existing file, not modifying some bytes in the existing file.

Problems with mode "wt" when using ContentResolver/ContentProvider

It might seem that a solution is to explicitly use mode "wt" instead of "w" if your intention is to replace the existing file. While this would definitely work for ParcelFileDescriptor.parseMode, as this is listed as a valid mode in the documentation, this may not always work when using a ContentResolver.open* API.

For example, if you change the provided sample app to use the mode "wt", then tap one of the save buttons and navigate to Google Drive in the SAF and try to save the file, the app crashes with the exception:

java.io.FileNotFoundException: Unsupported mode: wt
    at android.database.DatabaseUtils.readExceptionWithFileNotFoundExceptionFromParcel(DatabaseUtils.java:149)
    at android.content.ContentProviderProxy.openAssetFile(ContentProviderNative.java:631)
    at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:1521)
    at android.content.ContentResolver.openOutputStream(ContentResolver.java:1227)

My guess is because "wt" is not listed as a mode in the documentation of ContentProvider (as mentioned above), Google Drive does not support this mode. However, from my testing, Google Drive does actually treat mode "w" the same way that Android 9 and below did (with truncate).

However, when trying to support any ContentProvider for all API levels, this leaves the user in a predicament. Android 10+ requires mode "wt", but Google Drive crashes with this mode.

It turns out, mode "rwt" appears to work for both. My concern with this is that it's requesting read permission, which is unnecessary. While I have not discovered any issues (yet), I'm not sure if there is a ContentProvider which would balk at the read request.

Summary / Actions

1. It would be great to know if this was an intentional behavior change.

2. It would be helpful if this behavior change was documented on the ⁠Behavior Changes in Android 10 page.

3. It would be helpful if the documentation of ContentResolver and ContentProvider was updated to include mode "wt" and in general make sure that all the supported modes are listed and documented and align with ParcelFileDescriptor.parseMode, assuming that's the source of truth.

4. Since we can't use mode "wt" with ContentProviders like Google Drive (at least until Drive is updated to support it), it would be helpful to know what the recommended mode is. Are there any potential problems with using "rwt" or is it not a problem to include read permission?

5. My suggestion is to update the default mode used by ContentResolver.openOutputStream to include truncate (although I'm not sure if this should be "wt" or "rwt" due to the issues with Google Drive and potentially other ContentProviders). Alternatively, the mode could be left as "w" and the documentation updated to make it clear that the behavior of this method changed in Android 10 and that the user should instead call ContentResolver.openOutputStream with the desired mode (along with better documentation for the modes).

6. The extra MODE_CREATE should be removed from the test for mode "w".

Additional links

There's a react-native-fs thread discussing the issue (which is where I discovered the issue with mode "wt" and Google Drive).

I also found a related issue reported recently.