I am just clearing up my Android doubts. So lets talk about Services, we use services when we have to perform an operation in the background. Lets say Playing Music in the background? Thats one of the most popular reasons why people use Services.
But i just used Mediaplayer in my Mainactivity and i used .start() method in onCreate of my activity. I then minimized the app, but guess what....music still plays. I open the app again, and the music is still playing. I then remove the app from recent apps, basically destroying it and the music stops. Basically the app performs how it is supposed to. Works PERFECT!
Then why do we use services at all for these kind of tasks?
Is there any scenario this code might create a problem? Or is this creating some memory leak or something?
When "minimized" the App continues to play music due to OS delay which allow an User to re-open the App without delay (due to a closure mistake?) because all remained in memory (even the Music) in the previous state.
But the memory is limited, and the CPU the same, so the OS could kill or freeze (using Doze) a background Activity in any moment without prompt User/Developer.
An Activity could be killed to claim Memory or freezed to save CPU cycles. In this situation only explicitely declared Background Services are allowed to run (however with some limitations and special-behaviours), so if you don't use Service your Music could stop in any moment in the future.
PS: even Background Service could be killed from OS, but this case is very-very rare and only on Extreme Low Memory situations.
It will play as long as Android lets it live. It may stop at any moment, usually after 10-20 minutes.
Consider using Foreground Service to playback music. It will last until user kills it, and also provides notification bar with control over the playback.
Related
I am developing a video call app, and all of my camera, networking, encoding, decoding and audio are running in my activity.
The main problem is that whenever the user locks their screen or switches apps, the activity is shut down and I lose the call.
I've tried wakelocks, notifications, foreground services, nothing keeps my activity alive past Android 10.
Any suggestions?
It is normal for the activity to disappear when the memory is insufficient. You need to use the foreground service to keep the program. Just like the music player, they all use the foreground service.
Im a bit confused on background limitations of apps, and I could use an explanation. So, starting from android 8 we have limitations on services and sending broadcasts. As for now, we can only make service run in background if it has the foreground notification, otherwise it will be killed. The app is considered to be in background if none of it's activities are visible, and my questions are: 1. For how long can the app-process itself live without foreground service? For instance, if I go to home screen, thereby putting app in background my app can still play sounds for hours, but I expected it will be killed by system in a couple of minutes. 2. Is foreground service somehow related to application lifecycle? For instance,maybe if I start the foreground service then my app won't get killed or less likely to be killed by the system.
I'm asking all this because my app is using c++ libs to make VOIP calls and do other stuff in background and I'm wondering what would happen if I just open the home screen and leave my app working, so far I've never seen the system kill the app while the call is active.
For how long can the app-process itself live without foreground service?
Android low memory killer daemon monitors the system constantly. If there is high memory pressure, least essential process gets killed. If there is not a memory problem, your app might live in the background for a long time. However vendors might limit the number of background processes. If this limit is 3 and your app falls to 4th place, it gets killed even if there is no memory pressure. And some vendors just kill the unvisible apps and there is nothing you can do about it. You can check this answer for a similar problem on OnePlus devices.
Is foreground service somehow related to application lifecycle? For instance,maybe if I start the foreground service then my app won't get killed or less likely to be killed by the system.
According to Android Processes and Application Lifecycle documentation foreground services have the 2nd highest priority in the system. So the answer is yes, if you are running a foreground service, your app is less likely to be killed even if you do not have a visible Activity.
I read Anndroid document - http://developer.android.com/guide/topics/media/mediaplayer.html
which said ".. you want it to continue playing while the user is interacting with other applications—then you must start a Service and control the MediaPlayer instance from there. "
But I found if I start a local a music file from an activity, then leave that activity, ( for example, press HOME key and interact with another app ), the music continues playing.
So, I don't understand " the "must start a Service" in document. Did I miss something?
This was not a big obstacle for my app at this moment. I am just wondering what's the potential problems could be if I do not use Service.( Services have longer lifespan, so the mediaplayer could be killed earlier, any others ? )
Our development is based on Android 2.2.
Thanks for any help in advance.
Big reason, if you are not using a service, users cannot listen to music outside of your app when the the activity gets paused or terminated. Technically you can make a music app but if your users cant listen to music when another app is in the foreground or the phone is in a different state(locked) it wont make for a very good app. You should take a look at the activity lifecycle for a deeper understanding of the process. Note that this behavior is by design for saving power, memory and cpu cycles.
It helps also not to think of services in the more traditional desktop dev usage. You want this thing to live even when your activity is not up and about.
For more about activity life cycles Managing the Activity Lifecycle
For the How
http://www.androidcompetencycenter.com/2009/01/basics-of-android-part-iii-android-services/
For the why
Why is it important to use Services for background tasks?
Playing the music in the Activity might be fine for now, but when Android is low on resources it might try to kill your Activity. When you add a service to an app, Android will try to keep that process alive as long as possible if it falls under certain criteria (such as playing music). Read over the Process Lifecycle section on Services:
http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle
The activity can get killed by Android or by the user and then the music would stop playing.
I am designing an android app that needs to play a sound every minute while in its active state.
I have the logic that plays the sound every minute in the active state using a runnable and handler. The app works fine if you press the start or stop buttons.
If you run the app and hit stop it kills the app. If you run the app hit home the sounds continue to play and when you relaunch the timer will be up to date. This is expected.
The problem i am having is that if you hit home and then launch another app, there is a high chance my app gets killed and the sounds will no longer play (and consequently GUI will is reset when you relaunch)
My question is, What approach should i use so that my app will continue to play the sounds until i tell it to stop, even if its not in the foreground? The sounds can be thought of as a reminder to the user.
I have tried using the google machine to help me out but am having no luck.
If you run the app hit home the sounds continue to play and when you relaunch the timer will be up to date. This is expected.
Except that it won't last.
The problem i am having is that if you hit home and then launch another app, there is a high chance my app gets killed and the sounds will no longer play (and consequently GUI will is reset when you relaunch)
Correct.
What approach should i use so that my app will continue to play the sounds until i tell it to stop, even if its not in the foreground?
A service. With a period of one minute, you're on the borderline between where I think you should use AlarmManager and an IntentService and where your existing Handler approach can work.
You should use startForeground() with the service, both to keep Android from shutting it down, and to give the user a really easy way to get back to the activity to shut the thing up (via the Notification you establish via startForeground()).
I'm trying to write an Android application which will allow users to listen to a radio station.
I have got the start and stop buttons to work and it plays the stream. If I press the home key and start doing other bits and pieces with the phone, the stream continues to play. This is how I want it to work.
Should I bother creating a service to play the stream, or is the method I already use good enough? What benefit would having it in a service bring? A lot of tutorials and examples online seem to use services but it seems to me it's just adding extra complications into the code. Or is it more efficient?
Regards,
David
You don't need to use a service, but your users may under normal use find that playback stops unexpectedly, it depends on the normal use case, so a Service is the best approach.
The reason is due to the lifetime of the Activity that your streaming object / media player is currently attached to.
At some point the system will completely release the Activity now that it is no longer visible to the user, and once GC happens playback will stop. This will happen depending on memory pressure and what other actions the user takes, such as launching other apps. Services are allowed a longer life span, in general they will be released only after all other backgrounded activities are released but before the foreground activity. A more complete description of process lifecycle rules around Services can be found in the Android docs here.
You may also want to look at the PowerManager and the use of PARTIAL_WAKE_LOCK, which would allow playback to continue when the handset would normally sleep (at the cost of battery life).