TBA: users are reporting that can't download files

added Next label

added Bug label

A user on frontdesk has reported:

I am using the TOR browser for Android and I am not able to download pdf files. This message appears evey time: "Download Failed"

I can reproduce this bug as well from time to time (sometimes the downloads work as intended) for all types of files and not just PDFs.

mentioned in issue tor-browser#40740 (closed)

@championquizzer Could you let me know if you can still reproduce this (or not) after updating to 11.0.5/6 please?

@aguestuser I'd like to sit down and review the bugs we have open for Android once we've fully caught up with Fenix (and you're not otherwise distracted with releases). However in the meantime this one should take priority :)

OS: Android 12
Tor Browser for Android: 11.0.6

Steps: Launch Tor Browser for Android, let it bootstrap, try to download files of different MIME types and close the app. Repeated these steps exactly three times.

Files I tested with: .jpeg, .png, .pdf, .tar.gz

Result: I hit this bug twice and both times with jpeg files. The jpeg file failed to download and hitting on 'Retry' gave me a reloading progress bar which eventually failed after some minutes (as visible in the attached screenshot). All of the other file types downloaded just fine.

I know this isn't much helpful to actually debug but I am happy to assist. Thanks for looking into this!

assigned to @aguestuser

thanks @championquizzer :)

ps: @duncan this one is on my radar! will try to take a look ASAP! (under some definition of of "AP")

i was able to reproduce the error attempting to download a .jpeg and netted some logs.

here were my steps:

navigate to https://people.torproject.org/~aguestuser/img/gull-small.jpeg

long press the image, bringing up the options modal, tap "Save Image" from the modal
immediately see an error in the logs
observe that a download is being attempted in the activity bar
after 15 seconds observe that the download has failed, leaving following traces: (a) "Download Failed / Try Again" pop-up, (b) "Downlaod Failed" notification, (c) noisy error message w/ stack trace in logs

here are logs in question (which i will use to investigate further):

2022-02-11 12:50:29.235 2009-6191/system_process E/InputDispatcher: Window handle Window{c5d48f9 u0 org.torproject.torbrowser/org.mozilla.fenix.HomeActivity} has no registered input channel
### ~ 15 second delay, then:
2022-02-11 12:50:45.756 4149-4323/org.torproject.torbrowser E/AbstractFetchDownloadService: Unable to complete download for f3473a49-8da7-4744-b961-3a50f86b5a6c marked as FAILED
    java.io.FileNotFoundException: /storage/emulated/0/Download/gull-small.jpg: open failed: EACCES (Permission denied)
        at libcore.io.IoBridge.open(IoBridge.java:496)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:235)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$performDownload$1.invoke(AbstractFetchDownloadService.kt:40)
        at mozilla.components.concept.fetch.Response$Body.useStream(Response.kt:1)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.performDownload$feature_downloads_release(AbstractFetchDownloadService.kt:35)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.startDownloadJob$feature_downloads_release(AbstractFetchDownloadService.kt:5)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$handleDownloadIntent$1.invokeSuspend(AbstractFetchDownloadService.kt:2)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:18)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:11)
     Caused by: android.system.ErrnoException: open failed: EACCES (Permission denied)
        at libcore.io.Linux.open(Native Method)
        at libcore.io.ForwardingOs.open(ForwardingOs.java:167)
        at libcore.io.BlockGuardOs.open(BlockGuardOs.java:252)
        at libcore.io.ForwardingOs.open(ForwardingOs.java:167)
        at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7255)
        at libcore.io.IoBridge.open(IoBridge.java:482)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:235) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$performDownload$1.invoke(AbstractFetchDownloadService.kt:40) 
        at mozilla.components.concept.fetch.Response$Body.useStream(Response.kt:1) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.performDownload$feature_downloads_release(AbstractFetchDownloadService.kt:35) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.startDownloadJob$feature_downloads_release(AbstractFetchDownloadService.kt:5) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$handleDownloadIntent$1.invokeSuspend(AbstractFetchDownloadService.kt:2) 
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3) 
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:18) 
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1) 
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:11)

screen after failed download:

noting, i can reproduce on recent nightly/alpha testbuild (against fenix v96) as well...

system info:

fenix: 96.0a1 (Build #2015363077), build release
AC: 96.0.15, release build
GV: 96.0-20141228000000
AS: 86.2.2

observed behavior is almost identical to stable except a much shorter delay between download request and error message:

2022-02-11 13:33:21.736 2009-4782/system_process E/InputDispatcher: Window handle Window{ab2d63a u0 org.torproject.torbrowser_nightly/org.torproject.torbrowser_nightly.App} has no registered input channel
2022-02-11 13:33:23.066 6856-6904/org.torproject.torbrowser_nightly E/AbstractFetchDownloadService: Unable to complete download for 30774d7c-d23e-49d6-93f8-7449846351b2 marked as FAILED
    java.io.FileNotFoundException: /storage/emulated/0/Download/gull-small.jpg: open failed: EACCES (Permission denied)
        at libcore.io.IoBridge.open(IoBridge.java:496)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:235)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$performDownload$1.invoke(AbstractFetchDownloadService.kt:39)
        at mozilla.components.concept.fetch.Response$Body.useStream(Response.kt:1)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.performDownload$feature_downloads_release(AbstractFetchDownloadService.kt:35)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.startDownloadJob$feature_downloads_release(AbstractFetchDownloadService.kt:5)
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$handleDownloadIntent$1.invokeSuspend(AbstractFetchDownloadService.kt:2)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:18)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:10)
     Caused by: android.system.ErrnoException: open failed: EACCES (Permission denied)
        at libcore.io.Linux.open(Native Method)
        at libcore.io.ForwardingOs.open(ForwardingOs.java:167)
        at libcore.io.BlockGuardOs.open(BlockGuardOs.java:252)
        at libcore.io.ForwardingOs.open(ForwardingOs.java:167)
        at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7255)
        at libcore.io.IoBridge.open(IoBridge.java:482)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:235) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$performDownload$1.invoke(AbstractFetchDownloadService.kt:39) 
        at mozilla.components.concept.fetch.Response$Body.useStream(Response.kt:1) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.performDownload$feature_downloads_release(AbstractFetchDownloadService.kt:35) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService.startDownloadJob$feature_downloads_release(AbstractFetchDownloadService.kt:5) 
        at mozilla.components.feature.downloads.AbstractFetchDownloadService$handleDownloadIntent$1.invokeSuspend(AbstractFetchDownloadService.kt:2) 
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3) 
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:18) 
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1) 
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:10)

@sysrqb so clearly i need to go look at mozilla.components.feature.downloads.AbstractFetchDownloadService.performDownload, but it's unclear to me how that might interact with whatever various network patches we might have in place that it might now disagree with. ideas for how/where to investigate?

also: what are the hotspots (read: disabled capabilities around file I/O) that would cause EACCES (Permission denied) errors when IoBridge tries to open /storage/emulated/0/Download/gull-small.jpg ?

seeing if there does in fact exist a file at /storage/emulated/0/Download/gull-small.jpg and what its permissions are...

seeing nothing in that dir (via adb shell) and supposing the error was that we were trying to open a stream to write to that location and were unable to? (as suggested by error originating from FileOutputStream.<init>)

also curious what are InputDispatchers and "registered input channel"s...

mentioned in merge request tor-browser-build!406 (merged)

update: as per suggestion from @sysrqb i used the tpo arifact archives to perform a manul "bisect" procedure to identify the point in the tpo/fenix commit history we introduced the bug. findings are as follows:

api v28:

works for all apks tested (upto 11.5a4 <-- most reacent)

api v29:

bug introduced btw/:

- tbb v:      10.5a16      11.0a1[*]
- dates:      2021-06-10   2021-07-12
- tb-build:   41123dc2     0fb6a4d9
- fenix v:    v89.1.1 &    v90.0.0-beta.6
- tpo fenix:  dca9b30b2    322cd5aa
- AC v:       v75.0.22     v90.0.11
- tpo AC:     4cca6b8a19   0d763bf1df

[*] note: there was another android release (10.5a17 after this that also works, but it is confusing to consider it since it did not introduce any changes to the fenix layer, but merely adopts changes to the underlying noscript, tor, and tor launcher layers and the build environment)

NOTE: i cannot test for API versions 30 and higher, b/c I get the following error when trying to install the apk:

adb: failed to install tor-browser-11.0a5-android-x86-multi-qa.apk: Failure [-124: Failed parse during installPackageLI: Targeting R+ (version 30 and above) requires the resources.arsc of installed APKs to be stored uncompressed and aligned on a 4-byte boundary]

(which is captured in #40202 (closed) )

fwiw, i get the following logs on a working download (in versions 10.5a9 and earlier):

when prompted to grant permission to access the file system:

2022-02-14 18:03:02.758 523-3687/system_process I/ActivityTaskManager: START u0 {act=android.content.pm.action.REQUEST_PERMISSIONS pkg=com.android.permissioncontroller cmp=com.android.permissioncontroller/.permission.ui.GrantPermissionsActivity (has extras)} from uid 10130
2022-02-14 18:03:02.957 1891-4437/com.android.permissioncontroller W/OpenGLRenderer: Failed to choose config with EGL_SWAP_BEHAVIOR_PRESERVED, retrying without...
2022-02-14 18:03:03.011 1891-4437/com.android.permissioncontroller I/Gralloc4: mapper 4.x is not supported
2022-02-14 18:03:03.118 331-1171/? W/ServiceManager: Permission failure: android.permission.ACCESS_SURFACE_FLINGER from uid=10118 pid=1891
2022-02-14 18:03:03.119 523-548/system_process I/ActivityTaskManager: Displayed com.android.permissioncontroller/.permission.ui.GrantPermissionsActivity: +355ms

when downloading a second time after already granting permissions:

2022-02-14 18:05:36.068 523-1214/system_process I/system_server: oneway function results will be dropped but finished with status OK and parcel size 4
2022-02-14 18:05:36.068 523-1214/system_process I/system_server: oneway function results will be dropped but finished with status OK and parcel size 4
2022-02-14 18:05:36.118 4088-4088/? W/libTor.so: type=1400 audit(0.0:659): avc: denied { ioctl } for path="socket:[83194]" dev="sockfs" ino=83194 ioctlcmd=0x894b scontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tcontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tclass=tcp_socket permissive=0 app=org.torproject.torbrowser_alpha
2022-02-14 18:05:09.562 523-523/system_process W/NotificationHistory: Attempted to add notif for locked/gone/disabled user 0
2022-02-14 18:05:36.133 523-523/system_process W/NotificationService: Removed summary didn't match old notification: old=0|org.torproject.torbrowser_alpha|100|null|10130, removed=0|org.torproject.torbrowser_alpha|100|null|10130
2022-02-14 18:05:36.202 523-3687/system_process I/system_server: oneway function results will be dropped but finished with status OK and parcel size 4
2022-02-14 18:05:36.286 4088-4088/? W/libTor.so: type=1400 audit(0.0:660): avc: denied { ioctl } for path="socket:[83194]" dev="sockfs" ino=83194 ioctlcmd=0x894b scontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tcontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tclass=tcp_socket permissive=0 app=org.torproject.torbrowser_alpha
2022-02-14 18:05:36.438 4088-4088/? W/libTor.so: type=1400 audit(0.0:661): avc: denied { ioctl } for path="socket:[83194]" dev="sockfs" ino=83194 ioctlcmd=0x894b scontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tcontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tclass=tcp_socket permissive=0 app=org.torproject.torbrowser_alpha
2022-02-14 18:05:36.629 523-523/system_process I/chatty: uid=1000(system) Binder:523_3 identical 1 line
2022-02-14 18:05:36.630 523-523/system_process W/NotificationHistory: Attempted to add notif for locked/gone/disabled user 0
2022-02-14 18:05:36.710 4088-4088/? W/libTor.so: type=1400 audit(0.0:663): avc: denied { ioctl } for path="socket:[83194]" dev="sockfs" ino=83194 ioctlcmd=0x894b scontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tcontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tclass=tcp_socket permissive=0 app=org.torproject.torbrowser_alpha
2022-02-14 18:05:36.714 4088-4088/? W/libTor.so: type=1400 audit(0.0:664): avc: denied { ioctl } for path="socket:[83194]" dev="sockfs" ino=83194 ioctlcmd=0x894b scontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tcontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tclass=tcp_socket permissive=0 app=org.torproject.torbrowser_alpha
2022-02-14 18:05:36.822 4088-4088/? W/libTor.so: type=1400 audit(0.0:665): avc: denied { ioctl } for path="socket:[83194]" dev="sockfs" ino=83194 ioctlcmd=0x894b scontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tcontext=u:r:untrusted_app_29:s0:c130,c256,c512,c768 tclass=tcp_socket permissive=0 app=org.torproject.torbrowser_alpha
2022-02-14 18:05:36.902 0-0/? W/audit: audit_lost=242 audit_rate_limit=5 audit_backlog_limit=64
2022-02-14 18:05:36.904 0-0/? E/audit: rate limit exceeded

removed Next label

added Doing label

added UX label

mentioned in issue tor-browser#40283 (closed)

so, the hotspot on this bug seems to revolve around this commit in android-components (Ensure system download manager is not used ):

http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/commit/91e47e06105f8e7e3bd96ac535b54b9d743ebf2b

in which we introduce a feature toggle called BuildConfig.ANDROID_DOWNLOADS_INTEGRATION and always set it to false, which has the effect of blocking moz's intended call to useFileStreamScopedStorage and enforcing that we will always call useFileStreamLegacy instead, which is what happens in the error path above. (More specifically: useFileStreamLegacy errors when calling the FileOutputStream constructor in its second line.)[*]

at the commit above, introducing this feature toggle still works. however, by the time we jump to AC v90.0.11 and fenix v90.0.0-beta.6 (where we first observe the bug), it does not. not sure why, but trying to see what else changed in mozilla's usage of the AbstractFetchDownloadService in the move from AC 75.2.2 to AC 90.0.1 that we diverged from ...

very loose (and not entirely coherent) starting hypothesis: perhaps in the bump from fenix 89 to 90, mozilla introduced some change that would result in the complete deprecation of the "legacy" file storage -- instead of eliminating that code path from AC, they simply never call it from fenix. because mozilla no longer needs to use the "legacy" permission they need to call useFileStreamLegacy, they stop requesting it in fenix. we pick up that change and also stop requesting the permission. however, because mozilla has no removed useFileStreamLegacy from AC, and because we have enforced that we will always use it, we now call the legacy function in AC without the permission we need to use it being sought in fenix.

not the best hypo... but something to poke at...

--

[*] in general, it is suprising to me that we would want to block using scoped storage, since failure to adopt it is deprecated as insecure by google. however, i'm guessing there's something related to the fact that the moz impl uses a db to store download metadata and/or that android's native "download manager" does some metadata leaking we don't like, and were trying to get away with using the "legacy" download version for as long as possible? did we ever have a plan to implement scoped storage without using the android download manager?)

from first line of google's docs on scoped storage, it seems like our current approach of always opting out of scoped storage is expected to completely break downloads on all devices running Android 11 / API 30 or higher:

https://source.android.com/devices/storage/scoped

In Android 11 or higher, apps targeting API 30 or higher must use scoped storage. Previously in Android 10, apps could opt out of scoped storage.

which seems like an argument for figuring out how to support it? reading up on the implementation now... trying to figure out whether using scoped storage is possible without violating a trust boundary we are trying to draw between TBA and the android OS, other apps, etc... don't have quite as much context as i'd like to make that evaluation. input from @sysrqb would be appreciated!

and/or: @acat it looks like you made the original changes in http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/commit/91e47e06105f8e7e3bd96ac535b54b9d743ebf2b

curious: do you have any context on why we wanted to entirely block scoped storage as opposed to trying to explore a safe way of using it?

and/or: @anarcat-admin it looks like you made the original changes in

Different a*cat :)

whoops!

and it looks like they are gone?

reading up on the implementation now... trying to figure out whether using scoped storage is possible without violating a trust boundary we are trying to draw between TBA and the android OS, other apps, etc... don't have quite as much context as i'd like to make that evaluation. input from @sysrqb would be appreciated!

Looking at android-components#40002 (closed) and android-components!7 (merged), we weren't explicitly concerned about scoped storage. We don't want to use the system downloader because that will bypass the proxy, but I don't see any immediate concerns with using scoped storage.

curious: do you have any context on why we wanted to entirely block scoped storage as opposed to trying to explore a safe way of using it?

and, w.r.t. this, as you can see in android-components!7 (merged), we were only trying to maintain previous behavior and there wasn't any known breakage as a result of that at the time. Now that there is known breakage, we should look at alternatives.

in android-components!7 (merged), @acat indicates they were concerned to block usage of MediaStore, which is what the useFileStreamScopedStorage calls almost immediately.

(recall: we block useFileStreamScopedStorage from being called in favor of the legacy function that is curently breaking.)

here is where we block the call to scoped storage:

http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/blob/android-components-91.0.1-11.0-1/components/feature/downloads/src/main/java/mozilla/components/feature/downloads/AbstractFetchDownloadService.kt#L825-843

    @SuppressLint("NewApi")
    internal fun useFileStream(
        download: DownloadState,
        append: Boolean,
        block: (OutputStream) -> Unit
    ) {
        val downloadWithUniqueFileName = makeUniqueFileNameIfNecessary(download, append)
        updateDownloadState(downloadWithUniqueFileName)

        if (shouldUseScopedStorage()) {
            useFileStreamScopedStorage(downloadWithUniqueFileName, block)
        } else {
            useFileStreamLegacy(downloadWithUniqueFileName, append, block)
        }
    }

    @VisibleForTesting
    internal fun shouldUseScopedStorage() =
            BuildConfig.ANDROID_DOWNLOADS_INTEGRATION &&
            getSdkVersion() >= Build.VERSION_CODES.Q

here is what it calls:

http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/blob/android-components-91.0.1-11.0-1/components/feature/downloads/src/main/java/mozilla/components/feature/downloads/AbstractFetchDownloadService.kt#L884-912

    @TargetApi(Build.VERSION_CODES.Q)
    @VisibleForTesting
    internal fun useFileStreamScopedStorage(download: DownloadState, block: (OutputStream) -> Unit) {
        val values = ContentValues().apply {
            put(MediaStore.Downloads.DISPLAY_NAME, download.fileName)
            put(MediaStore.Downloads.MIME_TYPE,
                getSafeContentType(context, download.filePath, download.contentType)
            )
            put(MediaStore.Downloads.SIZE, download.contentLength)
            put(MediaStore.Downloads.IS_PENDING, 1)
        }

        val collection = MediaStore.Downloads.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
        val resolver = applicationContext.contentResolver
        var downloadUri = queryDownloadMediaStore(applicationContext, download)

        if (downloadUri == null) {
            downloadUri = resolver.insert(collection, values)
        }

        downloadUri?.let {
            val pfd = resolver.openFileDescriptor(it, "w")
            ParcelFileDescriptor.AutoCloseOutputStream(pfd).use(block)

            values.clear()
            values.put(MediaStore.Downloads.IS_PENDING, 0)
            resolver.update(it, values, null, null)
        } ?: throw IOException("Failed to register download with content resolver")
    }

i don't know enough about MediaStore to know how worried we shoudl be about it (or why @acat was worried). do you? perhaps a quick voices sync might help generate momentum?

on MediaStore: https://developer.android.com/reference/android/provider/MediaStore

i am especially curious about MediaStore.Downloads.getContentUri and queryDownloadMediaStore, but i don't know if i'm barking up a wrong tree!

queryDownloadMediaStore looks like this:

http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/blob/android-components-91.0.1-11.0-1/components/feature/downloads/src/main/java/mozilla/components/feature/downloads/AbstractFetchDownloadService.kt#L962-1006

@TargetApi(Build.VERSION_CODES.Q)
        @VisibleForTesting
        internal fun queryDownloadMediaStore(applicationContext: Context, download: DownloadState): Uri? {
            val resolver = applicationContext.contentResolver
            val queryProjection = arrayOf(MediaStore.Downloads._ID)
            val querySelection = "${MediaStore.Downloads.DISPLAY_NAME} = ?"
            val querySelectionArgs = arrayOf("${download.fileName}")

            val queryBundle = Bundle().apply {
                putString(ContentResolver.QUERY_ARG_SQL_SELECTION, querySelection)
                putStringArray(ContentResolver.QUERY_ARG_SQL_SELECTION_ARGS, querySelectionArgs)
            }

            // Query if we have a pending download with the same name. This can happen
            // if a download was interrupted, failed or cancelled before the file was
            // written to disk. Our logic above will have generated a unique file name
            // based on existing files on the device, but we might already have a row
            // for the download in the content resolver.

            val collection = MediaStore.Downloads.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
            val queryCollection =
                    if (SDK_INT >= Build.VERSION_CODES.R) {
                        queryBundle.putInt(MediaStore.QUERY_ARG_MATCH_PENDING, MediaStore.MATCH_INCLUDE)
                        collection
                    } else {
                        @Suppress("DEPRECATION")
                        setIncludePending(collection)
                    }

            var downloadUri: Uri? = null
            resolver.query(
                    queryCollection,
                    queryProjection,
                    queryBundle,
                    null
            )?.use {
                if (it.count > 0) {
                    val idColumnIndex = it.getColumnIndex(MediaStore.Downloads._ID)
                    it.moveToFirst()
                    downloadUri = ContentUris.withAppendedId(collection, it.getLong(idColumnIndex))
                }
            }

            return downloadUri
        }

so it's clearly writing some kind of metadata bout files being downloaded to some sort of db outside of our control. presumably it cleans that "row" up upon download completion. but it seems like this is the kind of behavior we are interested in disabling?

was there a way we could enable downloads previously without allowing android to store metadata bout the file being downloaded to some system-wide db?

You'll need to investigate and experiment.

was there a way we could enable downloads previously without allowing android to store metadata bout the file being downloaded to some system-wide db?

That sounds like a combo of android-components@55d641a9 and 2be3f44e

mentioned in issue android-components#40075 (closed)

since this bug seems to be solvable exclusively in the android-components layer, i have created a ticket in that repo to track it: android-components#40075 (closed)

i will likely close this ticket as superseded by the above if further investigation fails to turn up anything in the fenix layer that needs fixing.

mentioned in merge request android-components!80 (merged)

added Needs Review label and removed Doing label

mentioned in issue tor-browser-build#40427 (closed)

closed

removed Needs Review label

TBA: users are reporting that can't download files

Report 1:

Report 2:

Designs

Child items ...

Activity

api v28:

api v29: