[GH-ISSUE #1504] Potential UI thread blocking: bitmap decoding and file I/O in `ShareActivity` #1061

New issue

Open

opened 2026-05-07 00:29:58 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:29:58 +02:00

Owner

Originally created by @nbd-boss on GitHub (Dec 1, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1504

Description

In ShareActivity, both handleSendImage() and handleSendFile() perform potentially heavy operations on the main (UI) thread.

Relevant code

1. `handleSendImage()`

contentImage.setImageBitmap(fileUri!!.readBitmapFromUri(applicationContext))

The helper function readBitmapFromUri() performs:

contentResolver.openInputStream() → synchronous file I/O
BitmapFactory.decodeStream() → CPU-heavy bitmap decoding

Both operations run on the main thread.

2. `handleSendFile()`

val info = fileStat(this, fileUri)

fileStat() performs synchronous file access on the main thread.

Why this is a problem

Opening an InputStream from a resolver can be slow, especially for:
- large images
- cloud providers (Google Drive / OneDrive)
- SAF documents
- slow storage
BitmapFactory.decodeStream() is a known CPU-heavy operation.
These operations may block the UI thread and cause visible freezes or jank.

Google’s official guidelines state that file I/O and bitmap decoding should not be performed on the main thread.

Expected behavior

UI remains responsive while loading and decoding shared images or files.

Originally created by @nbd-boss on GitHub (Dec 1, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1504 ### **Description** In `ShareActivity`, both `handleSendImage()` and `handleSendFile()` perform potentially heavy operations on the main (UI) thread. ### **Relevant code** #### 1. `handleSendImage()` ```kotlin contentImage.setImageBitmap(fileUri!!.readBitmapFromUri(applicationContext)) ``` The helper function `readBitmapFromUri()` performs: * `contentResolver.openInputStream()` → synchronous file I/O * `BitmapFactory.decodeStream()` → CPU-heavy bitmap decoding Both operations run on the main thread. #### 2. `handleSendFile()` ```kotlin val info = fileStat(this, fileUri) ``` `fileStat()` performs synchronous file access on the main thread. --- ### **Why this is a problem** * Opening an InputStream from a resolver can be slow, especially for: * large images * cloud providers (Google Drive / OneDrive) * SAF documents * slow storage * `BitmapFactory.decodeStream()` is a known CPU-heavy operation. * These operations may block the UI thread and cause visible freezes or jank. Google’s official guidelines state that file I/O and bitmap decoding should not be performed on the main thread. --- ### **Expected behavior** UI remains responsive while loading and decoding shared images or files.