Describe the bug
After the app has not been opened for an extended period (hours to days), opening a book sometimes results in a WebView error screen showing net::ERR_FAILED on a URL with the internal Readium scheme (e.g. https://readium/publication/OEBPS/Text/cover.xhtml or .../Section0019.xhtml). Reopening the same book makes the issue go away.
How to reproduce?
This bug only surfaces after the app has been left unused for a long time. The two situations where users report it:
- The reader was closed (or the app was backgrounded) and the app was not opened for hours or days. The user then opens the app and taps on a book — instead of the book content, the WebView error screen with net::ERR_FAILED is shown.
- The device was locked for a long period with the app in the background. After unlocking and returning to the app, opening a book leads to the same error.
In both cases the trigger is extended inactivity of the app process while the device kept running. There are no specific manual steps that reliably reproduce it — it happens randomly and rarely, and depends heavily on how aggressively the OS / vendor reclaims background process resources. On some devices users hit it once a week, on others never.
The closest deterministic repro we found is enabling Developer Options → "Don't keep activities", which simulates the same lifecycle state the OS puts the app into after long inactivity.
Readium version
3.1.2
Android API version
11
Additional context
We are seeing an Android bug in our EPUB reader where, after the app has been unused for an extended period (hours to days), opening a book sometimes results in a WebView error screen showing net::ERR_FAILED on a URL with the internal Readium scheme (e.g. https://readium/publication/OEBPS/Text/cover.xhtml or .../Section0019.xhtml). Reopening the same book makes the issue go away.
Our working hypothesis is that the in-memory Publication object becomes unusable while the app is frozen in the background — either because the OS killed the process and restored the Activity, or because file descriptors / decompression caches / decryption sessions tied to the Fetcher were released by the OS. The interceptor backing the https://readium/ scheme then returns null, and the WebView falls back to its native ERR_FAILED page.
The bug is intermittent .
Has anyone else run into this same issue? Any pointers, similar reports, or suggestions on how to fix it would be hugely appreciated — we are stuck debugging this in production because it cannot be reliably reproduced and only surfaces through user complaints.
Describe the bug
After the app has not been opened for an extended period (hours to days), opening a book sometimes results in a WebView error screen showing net::ERR_FAILED on a URL with the internal Readium scheme (e.g. https://readium/publication/OEBPS/Text/cover.xhtml or .../Section0019.xhtml). Reopening the same book makes the issue go away.
How to reproduce?
This bug only surfaces after the app has been left unused for a long time. The two situations where users report it:
In both cases the trigger is extended inactivity of the app process while the device kept running. There are no specific manual steps that reliably reproduce it — it happens randomly and rarely, and depends heavily on how aggressively the OS / vendor reclaims background process resources. On some devices users hit it once a week, on others never.
The closest deterministic repro we found is enabling Developer Options → "Don't keep activities", which simulates the same lifecycle state the OS puts the app into after long inactivity.
Readium version
3.1.2
Android API version
11
Additional context
We are seeing an Android bug in our EPUB reader where, after the app has been unused for an extended period (hours to days), opening a book sometimes results in a WebView error screen showing net::ERR_FAILED on a URL with the internal Readium scheme (e.g. https://readium/publication/OEBPS/Text/cover.xhtml or .../Section0019.xhtml). Reopening the same book makes the issue go away.
Our working hypothesis is that the in-memory Publication object becomes unusable while the app is frozen in the background — either because the OS killed the process and restored the Activity, or because file descriptors / decompression caches / decryption sessions tied to the Fetcher were released by the OS. The interceptor backing the https://readium/ scheme then returns null, and the WebView falls back to its native ERR_FAILED page.
The bug is intermittent .
Has anyone else run into this same issue? Any pointers, similar reports, or suggestions on how to fix it would be hugely appreciated — we are stuck debugging this in production because it cannot be reliably reproduced and only surfaces through user complaints.