[Enhancement]: Move Android downloads to an active notification #774

New Issue

2026-04-24T23:37:26+02:00

adam commented

2026-04-24 23:37:26 +02:00

Originally created by @goose-ws on GitHub (Nov 24, 2023).

Describe the feature/enhancement

I'm currently remote to my server with a not blazing fast connection between us. I've been attempting to download a ~700 MB .m4b audiobook for offline play for my flight home. With my connection I've noticed that if I let my phone screen lock or if I switch to another app, the download fails/gets stuck within 1-2% of where I left it. I suspect that the Android OS is sleeping ABS in the background once it's been closed for a minute or two, interrupting the download. Debug logs from my server and indicate the socket is closing due to ping timeout, with timestamps matching the suspected behavior.

Other apps typically put an active notification in the notification drawer with a progress bar to show download progress. I suspect that helps prevent the app from being slept in the background while the download is in progress? I believe adding one here could help as well.

Originally created by @goose-ws on GitHub (Nov 24, 2023). ### Describe the feature/enhancement I'm currently remote to my server with a not blazing fast connection between us. I've been attempting to download a ~700 MB `.m4b` audiobook for offline play for my flight home. With my connection I've noticed that if I let my phone screen lock or if I switch to another app, the download fails/gets stuck within 1-2% of where I left it. I suspect that the Android OS is sleeping ABS in the background once it's been closed for a minute or two, interrupting the download. Debug logs from my server and indicate the socket is closing due to ping timeout, with timestamps matching the suspected behavior. Other apps typically put an active notification in the notification drawer with a progress bar to show download progress. I suspect that helps prevent the app from being slept in the background while the download is in progress? I believe adding one here could help as well.

adam added the enhancement android labels 2026-04-24 23:37:26 +02:00

adam commented

2026-04-24 23:37:27 +02:00

@advplyr commented on GitHub (Nov 24, 2023):

I tested this briefly on a Pixel 6 running Android 13 and the download continued in the background.
Can you share your device model and android version? As well as the mobile app version you are currently using and the server version?

The socket disconnection will not have anything to do with this. What may have something to do with it is your battery optimization setting. Can you share how long you are keeping the device asleep or any other details?

@advplyr commented on GitHub (Nov 24, 2023): I tested this briefly on a Pixel 6 running Android 13 and the download continued in the background. Can you share your device model and android version? As well as the mobile app version you are currently using and the server version? The socket disconnection will not have anything to do with this. What may have something to do with it is your battery optimization setting. Can you share how long you are keeping the device asleep or any other details?

adam commented

2026-04-24 23:37:27 +02:00

@DieselTech commented on GitHub (Nov 24, 2023):

Background killing of apps is really hard to tackle because different manufactures all use different aggressiveness when it comes to "optimizing" for battery life. It's even harder to test because there won't be a 1 size fits all approach. What's tested on a pixel 6 won't apply to a S23. In fact the pixels are listed as the gold standard when it comes to not killing working apps in the background.

https://dontkillmyapp.com/

I'd advise turning off any battery optimization features for your phone that target the ABS apk.

@DieselTech commented on GitHub (Nov 24, 2023): Background killing of apps is really hard to tackle because different manufactures all use different aggressiveness when it comes to "optimizing" for battery life. It's even harder to test because there won't be a 1 size fits all approach. What's tested on a pixel 6 won't apply to a S23. In fact the pixels are listed as the gold standard when it comes to not killing working apps in the background. https://dontkillmyapp.com/ I'd advise turning off any battery optimization features for your phone that target the ABS apk.

adam commented

2026-04-24 23:37:27 +02:00

@goose-ws commented on GitHub (Nov 25, 2023):

Ah, yeah, I hadn't considered battery optimization as the source of the problem.

I'm using a Pixel 8 Pro, Android 14, Build UD1A.231105.004

It's virtually stock android, as far as battery optimization goes it is stock android. I don't have any apps killing/restricting things in the background, nor am I enabling the build-in battery saver feature, etc.

Mobile app is 0.9.67-beta via Play Store.

Server is 2.5.0 via Docker on a Debian host.

I notice the behavior 2-3 minutes after I lock the screen and/or switch focus to another app without switching back.

I know how to pull logcat logs from my device as well, if that would be helpful.

@goose-ws commented on GitHub (Nov 25, 2023): Ah, yeah, I hadn't considered battery optimization as the source of the problem. I'm using a Pixel 8 Pro, Android 14, Build UD1A.231105.004 It's virtually stock android, as far as battery optimization goes it *is* stock android. I don't have any apps killing/restricting things in the background, nor am I enabling the build-in battery saver feature, etc. Mobile app is 0.9.67-beta via Play Store. Server is 2.5.0 via Docker on a Debian host. I notice the behavior 2-3 minutes after I lock the screen and/or switch focus to another app without switching back. I know how to pull logcat logs from my device as well, if that would be helpful.

adam commented

2026-04-24 23:37:28 +02:00

@goose-ws commented on GitHub (Nov 25, 2023):

To be more specific, here's the drill down:

Settings > Battery > Battery Saver (Off until below 10%)
Settings > Battery > Battery Saver > Use Adaptive Battery [Enabled]
Settings > Apps > App battery usage > audiobookshelf > Optimized [Default]

I'm home now but dropped off wifi/LAN to recreate the conditions over my mobile carrier, with logcat running.

I started the download and left the app active but locked the screen at 3%. I waited about 7 minutes and unlocked the screen, progress had gone up to 20%.

So I unlocked the device, minimized to the home screen. Waited roughly 90 seconds and I noticed in the server logs that my phone had disconnected due to ping timeout.

Unlocked the phone and pulled the app back up, and interestingly, I see in the server logs that my client reconnects and progress picks back up where it left off (27%). I did not experience that behavior of picking back up where it left off after a disconnect at the place I had been over the last week.

The biggest difference is that in the place where I was, I was on wifi, where as in my recreation just now I am using mobile data.

I'm happy to pass along the logcat output if it would be helpful or relevant (not sure if you'd rather just ignore this now that it's no longer an issue and I'm local to my server again). If you would like it, please just let me know what parts of it you need. It was a logcat via adb so lots of stuff in there.

@goose-ws commented on GitHub (Nov 25, 2023): To be more specific, here's the drill down: Settings > Battery > Battery Saver (Off until below 10%) Settings > Battery > Battery Saver > Use Adaptive Battery [Enabled] Settings > Apps > App battery usage > audiobookshelf > Optimized [Default] I'm home now but dropped off wifi/LAN to recreate the conditions over my mobile carrier, with logcat running. I started the download and left the app active but locked the screen at 3%. I waited about 7 minutes and unlocked the screen, progress had gone up to 20%. So I unlocked the device, minimized to the home screen. Waited roughly 90 seconds and I noticed in the server logs that my phone had disconnected due to ping timeout. Unlocked the phone and pulled the app back up, and interestingly, I see in the server logs that my client reconnects and progress picks back up where it left off (27%). I did not experience that behavior of picking back up where it left off after a disconnect at the place I had been over the last week. The biggest difference is that in the place where I was, I was on wifi, where as in my recreation just now I am using mobile data. I'm happy to pass along the logcat output if it would be helpful or relevant (not sure if you'd rather just ignore this now that it's no longer an issue and I'm local to my server again). If you would like it, please just let me know what parts of it you need. It was a logcat via `adb` so lots of stuff in there.

adam commented

2026-04-24 23:37:29 +02:00

@colvdv commented on GitHub (Mar 15, 2024):

I also noticed downloads ceasing if I don't keep the app active during the download.

Switching active apps disrupts it even with it still running in the background, and I don't have any settings blocking background usage that I am aware of.

I too would like to see an active download progress notification.

Device: Google Pixel 6
OS: GrapheneOS, Android 14

@colvdv commented on GitHub (Mar 15, 2024): I also noticed downloads ceasing if I don't keep the app active during the download. Switching active apps disrupts it even with it still running in the background, and I don't have any settings blocking background usage that I am aware of. I too would like to see an active download progress notification. Device: Google Pixel 6 OS: GrapheneOS, Android 14

adam commented

2026-04-24 23:37:30 +02:00

@avshyz-gs commented on GitHub (Apr 26, 2024):

I encountered the same problem, it's really annoying.

A workaround I've found is to stream at the same time any other audiobook, to prevent the app from freezing

@avshyz-gs commented on GitHub (Apr 26, 2024): I encountered the same problem, it's really annoying. A workaround I've found is to stream at the same time any other audiobook, to prevent the app from freezing

adam commented

2026-04-24 23:37:31 +02:00

@hydrian commented on GitHub (Jul 24, 2024):

I noticed this issue on Android 14 and not on often enough to be memorable on Android 13. This may have just been the android version of the client at the time, but it may be something to look into.

OS: Android 14
Device: moto g stylus 5G - 2023
Androud client version: 0.9.74-beta

@hydrian commented on GitHub (Jul 24, 2024): I noticed this issue on Android 14 and not on often enough to be memorable on Android 13. This may have just been the android version of the client at the time, but it may be something to look into. OS: Android 14 Device: moto g stylus 5G - 2023 Androud client version: 0.9.74-beta

adam commented

2026-04-24 23:37:31 +02:00

@newhinton commented on GitHub (Sep 11, 2024):

As far as i can tell, this has nothing todo with battery optimizations.

As far as i can tell, this is responsible for the downloads: (Please correct me if i'm wrong)
https://github.com/advplyr/audiobookshelf-app/blob/master/android/app/src/main/java/com/audiobookshelf/app/managers/DownloadItemManager.kt

This is then wrapped here:
https://github.com/advplyr/audiobookshelf-app/blob/master/android/app/src/main/java/com/audiobookshelf/app/plugins/AbsDownloader.kt#L14

First a caveat:
I do not know about how capacitor works, or what is calling that plugin. So my assumption may be entirely wrong.

The issue here is that the download is managed by the app's process itself. Something calls the plugin with the download items, and then the app downloads them. However: android quickly stops processing anything if the app is not in the foreground. From my observations, this is exactly what is happening.

To fix this, the actual download needs to be moved to either a ForegroundService or preferrably a workmanager worker
. Both of those have requirements like a notification, but they are otherwise excluded from background limitations.

@newhinton commented on GitHub (Sep 11, 2024): As far as i can tell, this has nothing todo with battery optimizations. As far as i can tell, this is responsible for the downloads: (Please correct me if i'm wrong) https://github.com/advplyr/audiobookshelf-app/blob/master/android/app/src/main/java/com/audiobookshelf/app/managers/DownloadItemManager.kt This is then wrapped here: https://github.com/advplyr/audiobookshelf-app/blob/master/android/app/src/main/java/com/audiobookshelf/app/plugins/AbsDownloader.kt#L14 First a caveat: I do not know about how capacitor works, or what is calling that plugin. So my assumption may be entirely wrong. The issue here is that the download is managed by the app's process itself. Something calls the plugin with the download items, and then the app downloads them. However: android quickly stops processing anything if the app is not in the foreground. From my observations, this is exactly what is happening. To fix this, the actual download needs to be moved to either a [ForegroundService](https://developer.android.com/develop/background-work/services/foreground-services) or preferrably a [workmanager worker ](https://developer.android.com/develop/background-work/background-tasks/persistent/getting-started). Both of those have requirements like a notification, but they are otherwise excluded from background limitations.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#774