Codecov Report

Attention: Patch coverage is 73.33333% with 16 lines in your changes missing coverage. Please review.

Project coverage is 58.22%. Comparing base (83899c6) to head (7b273c0).

@@             Coverage Diff              @@
##               main    #4015      +/-   ##
============================================
+ Coverage     57.72%   58.22%   +0.50%     
- Complexity     1586     1610      +24     
============================================
  Files           314      314              
  Lines         13046    13105      +59     
  Branches       1658     1669      +11     
============================================
+ Hits           7531     7631     +100     
+ Misses         4412     4356      -56     
- Partials       1103     1118      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Why do we have to handle the files from the "Download" differently? Your code implies that with the information given in the ContentUri, you can neither open nor copy the file! This seems not normal at all!

What will happen if this fallback is triggered for a file which is not in the Download called directory?! You are aware that Firefox can save file in other places than the "Download" directory!

Why do we have to handle the files from the "Download" differently? Your code implies that with the information given in the ContentUri, you can neither open nor copy the file! This seems not normal at all!

@kelson42 We are using this fallback method to handle ZIM files opened directly from browsers and file pickers. While we can open files using the provided Uri, we need the actual file path for libkiwix. On Android 11 and above, file managers return a Uri with the com.android.providers.downloads.documents/{documentId} authority when a file is opened from the "Download" folder (to ensure proper functionality with SAF). Our fallback method is applied in such cases.

In contrast, when opening files from locations outside the "Download" folder, either through the file picker or directly in the file manager, the returned Uri usually comes with the com.android.externalstorage.documents authority, which includes the correct file path. For example: content://com.android.externalstorage.documents/document/primary%3ADownload%2Fbeer.stackexchange.com_en_all_2023-05.zim. We handle this case properly.

However, when clicking on ZIM files directly from browsers, they use their own content provider to return a Uri, and the files are placed in the "Download" folder. That's why our fallback method specifically handles this case.

What will happen if this fallback is triggered for a file which is not in the Download called directory?! You are aware that Firefox can save file in other places than the "Download" directory!

Our method was not designed to properly open the ZIM files when we directly click on the browsers since browsers give the Uris with their own file provider(Maybe this is a reason for scanning feature is there). Since contentResolver can not provide the direct path for the file provider's uri since he thinks they are private files of the application(A reason to protect the files for the application, so other files can not overwrite the files of the application, they enforce the other apps to work directly with the uri so that original file could not affect).

Firefox can save files in other places like, in its own data directory and "Download" folders, on other places any browser does not put their files. Also, all browsers download their files in the Download directory since this directory is specially designed for downloading the files(And it is recommended, user-friendly, and perfect to work with SAF). So that's why Firefox will not save the downloaded files in other places.

Here we are fixing two scenarios:

1. Opening files via file picker:

   1. Here if we pick any files from storage via file pikcer or directly click on the file in file manager it returns document type uri content://com.android.externalstorage.documents/document/primary%3ADownload%2Fbeer.stackexchange.com_en_all_2023-05.zim which we are properly handling.
   2. When we pick the file from the download folder then it returns the content://media/external_primary/downloads/1000000069 downloads type uri for this, our fallback method will work.

2. For directly opening the files from browser:

   1. As all the browsers download their files in download folder so we first trying to resolve the URI with content resolver if it fails then we open the ZIM file via our fallback method.

This is why our fallback method is focused on handling files from the "Download" folder.

In my current testing, now this method is working fine with all Android 11 and above devices including all the phones and tablets. But I was testing with the older devices in those devices, there is also now all our functionality is working fine with browsers like it is working in the Android 11 and above. But there is some issue when we are opening directly from the file manager.

Since below Android 11, most of the file managers are working fine. But in some devices when we clicks on the file in file manager they provide the ZIM file with their own file provider(e.g. in huawei phones). For this issue, I have placed a fix in this PR. Also, refactored the code to handle those cases, where the user selects the file from other folders, and the contentQuery method does not return the path.