#Android App Crash when Writing Large File Using writeFile

12 messages · Page 1 of 1 (latest)

long storm
#

Hello,
I'm encountering an issue when attempting to save a large file (150 MB) downloaded from the internet to disk using the fs plugin with writeFile. Here's a simplified version of the code I'm using:

async function downloadAndSaveFile(url, fileName) {
  try {
    const response = await fetch(url, { method: 'GET' });

    if (!response.ok) {
      throw new Error(`Error downloading file: ${response.statusText}`);
    }

    const fileData = new Uint8Array(await response.arrayBuffer());
    const contentLength = response.headers.get('content-length');
    console.log(`File size: ${contentLength} bytes, actual downloaded data size: ${fileData.byteLength} bytes`);

    // Write the entire file to disk in a single operation
    await writeFile(fileName, fileData, {
      baseDir: BaseDirectory.AppCache,
      create: true
    });

    console.log(`File ${fileName} successfully saved in cache directory.`);
  } catch (error) {
    console.error(`Error downloading or saving file: ${error}`);
  }
}

The code works perfectly for smaller files (tested with files around 11 MB), confirming that the necessary write permissions for the plugin are in place. Additionally, the device has sufficient storage and memory. However, when trying to save a larger file (150 MB), the app crashes during the write operation.

Could this be an issue with memory allocation when handling larger files, or is there an additional configuration or limitation with the fs plugin when processing large files? Any advice or suggestions would be greatly appreciated.

Thank you!

#

Here’s the log output when the crash occurs:

11-13 20:48:15.122  5937  5950 I rada.gmlaunche: Background concurrent copying GC freed 6145(459KB) AllocSpace objects, 4(112KB) LOS objects, 13% free, 150MB/174MB, paused 85us total 125.140ms
11-13 20:48:16.334  5937  5937 I Tauri/Console: File: http://tauri.localhost/main.js - Line 215 - Msg: File size: 155207942 bytes, actual downloaded data size: 155207942 bytes
11-13 20:48:26.176  5937  5970 I RustStdoutStderr: WARNING: linker: Warning: "/data/app/com.google.android.webview-l9aqN0dYsZPugavdXaFf3w==/base.apk!/lib/arm64-v8a/libwebviewchromium.so" unused DT entry: unknown processor-specific (type 0x70000001 arg 0x0) (ignoring)
11-13 20:48:26.539  5937  5970 I RustStdoutStderr: [1113/204826.538836:ERROR:ptrace_client.cc(364)] Broker Open: access denied
11-13 20:48:26.645  5937  5970 I RustStdoutStderr: [1113/204826.645207:ERROR:socket.cc(182)] incorrect payload size 0
11-13 20:48:26.800  5937  6004 W cr_ChildProcessConn: onServiceDisconnected (crash or killed by oom): pid=6005 bindings:W  S
11-13 20:48:26.806  5937  5937 E chromium: [ERROR:aw_browser_terminator.cc(165)] Renderer process (6005) crash detected (code 5).
11-13 20:48:26.806  5937  5970 I RustStdoutStderr: [ERROR:aw_browser_terminator.cc(165)] Renderer process (6005) crash detected (code 5).
11-13 20:48:26.808  5937  5937 F chromium: [FATAL:crashpad_client_linux.cc(745)] Render process (6005)'s crash wasn't handled by all associated webviews, triggering application crash.
11-13 20:48:26.808  5937  5970 I RustStdoutStderr: [FATAL:crashpad_client_linux.cc(745)] Render process (6005)'s crash wasn't handled by all associated webviews, triggering application crash.
--------- beginning of crash
11-13 20:48:26.808  5937  5937 F libc    : Fatal signal 5 (SIGTRAP), code 1 (TRAP_BRKPT), fault addr 0x7e26ff9208 in tid 5937 (rada.gmlauncher), pid 5937 (rada.gmlauncher)
stone fractal
#

Can you try tauri android dev --release ? Just wanna see if that improves things a bit.

#

But generally the IPC is a bit more limited on Android because we're forced to use the message api (like in tauri v1)

long storm
#

I haven't tried running it with the --release flag yet. Once I do, I'll let you know. I tried splitting it into 4MB chunks and writing through append, but surprisingly, writing one chunk, according to the log, took about 6-7 seconds, which seems very strange. For now, I’ve set this approach aside without investigating the cause of such a significant delay.

long storm
stone fractal
#

in that case please open a github issue, at least with the create approach it shouldn't crash

long storm
# stone fractal in that case please open a github issue, at least with the create approach it sh...

It seems to me that the issue is not with the command itself but with the size of the payload being transferred. I even tried simply wrapping all the downloaded bytes in Base64 and sending them to my command to check the string length that arrives on the Rust side, and I encountered the exact same software crash. I don't see any memory leaks and can't figure out why it's crashing.

Are there any settings that might allow the WebView to handle larger data volumes?

stone fractal
#

i don't think there are

#

but i mean, the webview itself can handle that amount, it's the postMessage api apparently that can't (if it's not just file writing that fails). i'm pretty sure that there no settings for that api at all.
but still it shouldn't have a "global" limit, just a per message one 🤔 (which would mean chunking should prevent crashes)