Closed dankydev closed 3 years ago
Additional context I apologize if this behavior is not your responsibility. I do need my app to reproduce music when the screen is locked, this is one of the last milestones to get it done. I would be extremely grateful if you helped me finding a solution. Thanks in advance. Greetings
Please read at least the first 3 sentences of the README.
Also in future, please read and follow the instructions in the first section of the bug report carefully.
1) I read the first 3 sentences, i'm not blind. I specified the method name and how it behaved: what's the point? 2) Since i don't precisely know how just_audio is internally made, i'm reporting an issue here knowing it could be a problem of a third-part library, i've even apologized for that. Next time i won't disturb, or i will directly use another plugin. 3) I managed to solve it by myself, and the problem was not related to just_audio, so i still apologize for wasting your time.
For anyone interested, i report here the solution i found: https://pastebin.com/8rpMyBNS
- I read the first 3 sentences, i'm not blind. I specified the method name and how it behaved: what's the point?
Please understand that there are many genuine bugs that I need to sort through and fix, and it keeps me extremely busy. If you think you have found a bug, you did the right thing by clicking through to the bug report template, but I have put certain instructions in the bug report template specifically to help me cope with the large number of issues I have in the backlog. They are intended to serve as almost as a check list for the submitted to first establish that it can be classified as a bug (i.e. where the plugin didn't do what the documentation said it would do.)
In this case, the point of the first section of the bug report is not to describe how a method behaves, but rather to explain how that behaviour is "different" from the intended/documented behaviour, and this is necessary to establish that it is a bug, as opposed to it not working the way you personally would like. Ultimately, the plugin is only supposed to work as documented. The only documentation anywhere in this plugin that pertains to what happens when the app is not in the foreground is in the first 3 sentences of the README (i.e. audio_service), so you would need to point to that relevant documentation and explain how you have done what the documentation said in sentence 3 but it still didn't behave as expected, otherwise I would consider this as not a bug (which in fact it is not). So that is the purpose of those instructions. I appreciate that you are willing to submit a bug report, although in future, please ensure that you go through the checklist to ensure that the behaviour you wanted was actually intended behaviour.
For anyone interested, i report here the solution i found: https://pastebin.com/8rpMyBNS
This is not a complete solution because apps are not allowed to keep running in the background after a certain amount of time has elapsed, and so a foreground service is required, which is provided by audio_service, cited in the 3rd sentence of the README file. If you already used audio_service according to its instructions but it failed to maintain the background execution context, then that is a bug in audio_service, and I would encourage to lodge a bug with that project, but it is not clear to me from the present bug report that you actually used audio_service as per sentence 3 of the README. Did you?
This is not a complete solution because apps are not allowed to keep running in the background after a certain amount of time has elapsed, and so a foreground service is required, which is provided by audio_service, cited in the 3rd sentence of the README file. If you already used audio_service according to its instructions but it failed to maintain the background execution context, then that is a bug in audio_service, and I would encourage to lodge a bug with that project, but it is not clear to me from the present bug report that you actually used audio_service as per sentence 3 of the README. Did you?
Yes, the application implements the latest version of audio_service (0.15.1), and now it seems to work fine with the battery optimization fix i reported. I'll make several tests running the player for long periods, to be sure there are no problems with audio_service. If the error persists, i'll open an issue on that repository. Thanks for your help, i'll make you know.
This is not a complete solution because apps are not allowed to keep running in the background after a certain amount of time has elapsed, and so a foreground service is required, which is provided by audio_service, cited in the 3rd sentence of the README file. If you already used audio_service according to its instructions but it failed to maintain the background execution context, then that is a bug in audio_service, and I would encourage to lodge a bug with that project, but it is not clear to me from the present bug report that you actually used audio_service as per sentence 3 of the README. Did you?
So, i did many tests and the fix seems to work well. Anyway, i've posted a question on Stackoverflow regarding audio_service, since it's not certain to be a bug. You can find it here: https://stackoverflow.com/questions/64401540/audio-service-need-to-ignore-battery-optimizations-to-keep-the-background-servi
Hi @dankydev I would still consider this a likely bug in audio_service, and would recommend submitting a bug report on that project. If you submit a bug report with a minimal reproduction project, reproduction steps and device info, it will be possible for me to investigate.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with just_audio.
Which API doesn't behave as documented, and how does it misbehave? Just_Audio 0.5.2, Android API 30 and 31. When i turn off the screen of the emulator/physical device, i receive the error reported below after calling audioPlayer.setUrl (when the screen is on, everything goes as it should). Since it seemed to be caused by the Android's sleep policy, i tried changing to the always-on one:
adb shell settings put global wifi_sleep_policy 2
adb shell settings get global wifi_sleep_policy
But the error persists
Minimal reproduction project The example project should be sufficient.
To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior:
Error messages
Expected behavior I do need connectivity to be constantly active even when the screen is locked: is this related to AudioPlayer or ExoPlayer? a network-oriented music application not working when screen is locked wouldn't be nice...
Screenshots Not needed
Desktop (please complete the following information):
Smartphone (please complete the following information):
Flutter SDK version
Additional context I apologize if this behavior is not your responsibility. I do need my app to reproduce music when the screen is locked, this is one of the last milestones to get it done. I would be extremely grateful if you helped me finding a solution. Thanks in advance. Greetings