Significant downloadFile performance improvement in v8 despite using LegacyFilesystemImplementation

[chickengir1]

Summary

After upgrading @capacitor/filesystem from 6.0.3 to 8.0.0, we observed a ~3x download speed improvement. However, upon code inspection, downloadFile delegates to LegacyFilesystemImplementation which appears to have identical logic to v6.

We're curious what might explain this performance gain.

Environment

Package	Before	After
@capacitor/filesystem	6.0.3	8.0.0
@capacitor/core	6.2.1	8.0.1
Platform	Android	Android

Test Results

File: 158MB video file (BigBuckBunny.mp4)
Network: Wi-Fi
Measurement: 5 runs each version

Version	Average	Speed
6.0.3	~15.0s	~10 MB/s
8.0.0	~5.5s	~28 MB/s

Code Analysis

In v8.0.0, downloadFile is marked as @Deprecated and calls legacy implementation:

// FilesystemPlugin.kt (8.0.0)
@Deprecated("Use @capacitor/file-transfer plugin instead")
fun downloadFile(call: PluginCall) {
    legacyImplementation?.downloadFile(call, bridge, emitter, callback)
}

The buffer size (1024 bytes), progress throttle (100ms), and HTTP client (HttpURLConnectionBuilder) appear unchanged.

Question

Since downloadFile uses the legacy implementation without coroutines, what could explain this significant performance improvement?

• Capacitor core/bridge layer optimizations?
• JVM/Kotlin runtime differences?
• Something else we might have missed?

Any insight would be appreciated! 🙏

[chickengir1]

I found a potentially related issue: #6861 (Android Bridge Plugin Calls Queued - FileSystem.downloadFile blocking other requests)

Could the bridge-level fix for this issue be contributing to the performance improvement we observed? 🤔

[MILLERMARRU]

I checked whether #6861's fix is the explanation, and I don't think it is. That issue was about the Android bridge queuing other plugin calls behind a running downloadFile, not about downloadFile's own throughput. And looking at Bridge.java on the current main branch, plugin calls are still dispatched through a single Handler backed by one HandlerThread (taskHandler), not a thread pool, so whatever fix landed for #6861 didn't change the fundamental threading model you'd expect to explain a 3x raw transfer speedup. I couldn't find anything in the Capacitor core or Android CHANGELOGs between 6.x and 8.x that touches the bridge's networking path either.

Given the Kotlin download loop itself is confirmed identical, my best guess is this isn't a Capacitor code change at all, but an environment difference: Android's HttpURLConnection is backed by the platform's own network stack (OkHttp under the hood on modern Android), and its connection pooling/keep-alive/TLS session-reuse behavior can differ based on the app's targetSdkVersion, which Capacitor 8's Android tooling requirements likely bumped compared to whatever you were building against for 6.0.3. A newer targetSdk can get you cheaper TLS handshakes and better connection reuse from the OS without a single line of app code changing. It's also worth double-checking whether the Android System WebView package itself (which updates independently via Play Store) was the same version across your two test runs, since that's another variable that wouldn't show up in a package.json diff at all.

If you want to actually confirm which of these it is rather than guess: run both versions through Android Studio's Network Profiler (or a proxy like mitmproxy) and compare connection count/TLS renegotiation for the same 158MB request. If the v8 run reuses one keep-alive connection while v6 renegotiates per-chunk or opens multiple connections, that's your answer, and it'd be independent of anything in LegacyFilesystemImplementation.