Extracting an archive opened via content:// URI (Open with…) silently does nothing — cached temp file is deleted by TrashBin before ExtractService runs

Open
  • Is something wrong?
#4,760 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 7 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
android, kotlin
Domain
backend, mobile

Research direction

Start by tracing how MainActivity handles the incoming VIEW intent and how the archive viewer retains or cleans up the cached workspace file; then follow the source path passed to ExtractService. The report includes no source file or test names, so first locate those entry points and inspect the relevant lifecycle and cleanup code. Done when opening an archive from Amaze and extracting it from the viewer both work reliably, with a clear error if the source is missing.

Written by the indexing model from the issue text.

Description

Tapping an archive in Amaze's file list does not open it in Amaze's built-in archive viewer. Instead, the system "Open with" dialog appears. If I choose Amaze there, the archive opens in Amaze through a content://com.amaze.filemanager/... URI. Pressing Extract from that view does nothing: no progress, no extracted files, and only a toast that disappears quickly.

Extracting the same archive with long-press → Extract from the file list works.

The log shows that Amaze deletes its own cached copy of the archive (cache/workspace-<uuid>.zip) about 100 ms after the VIEW intent arrives. When Extract is pressed, ExtractService starts and stops within about 130 ms because the source file no longer exists.

Steps to reproduce
  1. Open Amaze and browse to a .zip file in internal storage (e.g. /storage/emulated/0/Download/test.zip).
  2. Tap the zip file. The system "Open with" chooser appears.
  3. Choose Amaze File Manager.
  4. The archive contents are shown.
  5. Tap Extract.
Expected behavior
  • Tapping an archive inside Amaze opens it directly in Amaze's archive viewer, without the "Open with" dialog.
  • Extract from the archive viewer extracts the files, as long-press → Extract does.
Actual behavior
  • The "Open with" dialog appears for an archive that is already inside Amaze.
  • After choosing Amaze, Extract does nothing. ExtractService stops almost immediately, the progress notification is posted and removed right away, and nothing is extracted.
Workaround

⋮ the archive in the file list → Extract works.

Relevant logcat
# Amaze (uid 10602) sends VIEW intent to itself with a content:// URI; delivered to existing singleInstance MainActivity
10-27 09:54:56.836 I/ActivityTaskManager(1681): START u0 {act=android.intent.action.VIEW dat=content://com.amaze.filemanager/... typ=application/zip flg=0x1 cmp=com.amaze.filemanager/.ui.activities.MainActivity} with LAUNCH_SINGLE_INSTANCE from uid 10602 (sr=233552640) (BAL_ALLOW_VISIBLE_WINDOW) result code=3

# ~110 ms later the cached workspace copy is deleted (going through TrashBin)
10-27 09:54:56.948 W/TrashBin(20472): Failed to move to bin /data/user/0/com.amaze.filemanager/cache/workspace-01a17a88-62de-7639-8a11-dfe3ad88bda8.zip
10-27 09:54:56.956 W/ModernMediaScanner(3522): Failed to visit /data/data/com.amaze.filemanager/cache/workspace-01a17a88-62de-7639-8a11-dfe3ad88bda8.zip: java.nio.file.NoSuchFileException: /data/data/com.amaze.filemanager/cache/workspace-01a17a88-62de-7639-8a11-dfe3ad88bda8.zip
10-27 09:54:56.958 D/MediaScannerConnection(20472): Scanned /data/user/0/com.amaze.filemanager/cache/workspace-01a17a88-62de-7639-8a11-dfe3ad88bda8.zip to null

# User presses Extract; service starts and stops after ~130 ms
10-27 09:55:01.249 I/ActivityManager(1681): Background started FGS: Allowed [callingPackage: com.amaze.filemanager; callingUid: 10602; uidState: TOP ; ... intent: Intent { cmp=com.amaze.filemanager/.asynchronous.services.ExtractService }; ... targetSdkVersion:36 ...]
10-27 09:55:01.379 D/ActivityManager(1681): Stop FGS timeout: ServiceRecord{739f83c u0 com.amaze.filemanager/.asynchronous.services.ExtractService c:com.amaze.filemanager}
10-27 09:55:01.466 I/NotificationService(1681): Cannot find enqueued record for key: 0|com.amaze.filemanager|1|null|10602
10-27 09:55:01.467 I/NotificationService(1681): Cannot find enqueued record for key: 0|com.amaze.filemanager|1|null|10602
10-27 09:55:01.470 I/NotificationService(1681): Cannot find enqueued record for key: 0|com.amaze.filemanager|1|null|10602
10-27 09:55:03.559 W/NotificationService(1681): Toast already killed. pkg=com.amaze.filemanager token=android.os.BinderProxy@8eb93c9
Analysis / possible cause
  • The VIEW intent goes to the already-running singleInstance MainActivity (result code=3 = START_DELIVERED_TO_TOP, so onNewIntent). Right after that, the workspace-<uuid>.zip cache file is deleted. Possibly the cleanup of the previous archive viewer or fragment deletes the workspace file that the new viewer is using. Another possibility is that cleanup runs at the wrong point in the lifecycle when a new intent arrives.
  • The temporary cache file is deleted through the TrashBin code path. That seems unintended for internal cache files: they should be deleted outright, not moved to the recycle bin.
  • ExtractService gets a source path that no longer exists and quits silently. It should show a clear error, such as "archive not found", in the notification as well as in a toast that is easy to miss.
  • Separately, tapping an archive in Amaze's own file list should open the internal viewer directly instead of showing the system "Open with" chooser.
Environment
  • Amaze version: 3.11.4 F-Droid build
  • Android version: Android 15
  • Device: Note 8T
  • Storage location of archive: Download
  • "All files access" granted: yes

2026-10-27-09-55-36.txt

Dominant language
Kotlin
Stars
6.5k
Forks
1.7k
Avg merge
1d 21h
Merged PRs (30d)
4

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TeamAmaze/AmazeFileManager

All issues in TeamAmaze/AmazeFileManager

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.