Fixed: In Samsung tablet of Android 14, downloaded files can not be opened via file picker or deep linking in non-PS variant.

[MohitMaliFtechiz]

Fixes #4008

• When we open a file from different browsers, they provide a URI through their own file provider, and the content resolver cannot retrieve the file path for these types of URIs. To fix this issue, we have introduced a fallback method that returns the exact path of the file located in the Downloads folder.
• Another issue we encountered on tablets is that the URIs are different from those on regular mobile devices, and our documentProviderContentQuery method could not return the path for these types of URIs from the Downloads folder. To fix this issue, we used our fallback method to retrieve the file path for these URIs.

**Before Fix **

BeforeFix.mp4

After Fix

AfterFix.mp4

File opening issue from the file manager in Huawei phones:

Before fix:

BeforeFix.mp4

After Fix:

XRecorder_04102024_163619.mp4

• Added the proper comments on methods for dev's reference, why we are using those methods.

[codecov]

Codecov Report

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

Project coverage is 57.99%. Comparing base (eaa28d6) to head (946b5cc).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
...rg/kiwix/kiwixmobile/core/utils/files/FileUtils.kt	73.33%	8 Missing and 8 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #4015      +/-   ##
============================================
+ Coverage     57.90%   57.99%   +0.09%     
- Complexity     1499     1513      +14     
============================================
  Files           315      315              
  Lines         13066    13125      +59     
  Branches       1660     1671      +11     
============================================
+ Hits           7566     7612      +46     
- Misses         4408     4415       +7     
- Partials       1092     1098       +6     

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

[kelson42]

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!

[MohitMaliFtechiz]

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.

[kelson42]

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.

Why do you talk about libkiwix here? We have to move/copy the ZIM file to the app directory, this is not done via libkiwix!

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.

We don't open ZIM file file with libkiwix outside the app folders... so what is the point here?

[MohitMaliFtechiz]

Why do you talk about libkiwix here? We have to move/copy the ZIM file to the app directory, this is not done via libkiwix!

@kelson42 I think you misunderstood this PR, it is for the non-ps variant where we open the file from file path directly. In PS-variant the copy/move functionality is working fine which we have fixed in #4006.

We don't open ZIM file file with libkiwix outside the app folders... so what is the point here?

This point is valid for PS variant, but here we are fixing the non-PS variant issue where we can open the files directly from storage with the file path as we have the MANAGE_EXTERNAL_PERMISSION in non-PS variant.