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.
Related
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.
I have an instance of Android MediaRecorder running in a LifecycleService that has been bound to (bindService) and started (startService) by an activity.
The MediaRecorder is meant to be recording audio, even when the activity itself is in the background, due to other apps being open on the screen.
I'm aware that Android can sometimes close services under certain circumstances, such as it needing resources elsewhere.
Do I need to worry that Android could close a bound, started service like mine?
In the circumstance that concerns me, the service would still have a binding (the activity), and it would still had an active task (the recording would running), so based on this Stackover answer it would have two reasons not to disappear. But is that enough to guarantee that the service will survive?
If not, are there steps I can take to ensure the service never disappears? A wakelock in the service, for instance?
And out of curiousity, would the fact that the service is running MediaRecorder make any difference? Surely Android would know not to close an active MediaRecorder session, no?
Lastly, if services are arbitrarily closed despite all efforts to prevent it, is there a better class I could be using for my MediaRecorder, one that can keep running in the background even when the Activity/Fragment is in the background?
thanks
John
i'm building app for listening to acc stream. I m using this library:
https://code.google.com/p/aacdecoder-android/
Especially this player.
PlayerCallback clb = new PlayerCallback() { ... };
MultiPlayer aacMp3Player = new MultiPlayer( clb );
aacMp3Player.playAsync( "http://..." ); // URL of MP3 or AAC stream
It's playing in AsyncTask, but for some smarphones when you put app to backround playing just stop.
Only in methond onDestroy i'm stopping AsyncTask, not in onPause or oStop.
Anyone have an idea why player stops?
Short answer: Music streaming apps need to have a Service running to avoid being terminated by Android.
On a cheaper device or when memory resources run low, Android will simply terminate processes as soon as they go into the background or when more memory is needed. This likely explains why it only happens on "some smartphones" as you mentioned. You can also go into the Developer Options on your phone and play with the "Don't Keep Activities" and "Background process limit" settings to simulate the same thing.
You can read more about how Android prioritizes processes and activities for termination when they are not the active app in the foreground at this link here. You'll read that Services are at higher priority for being kept around than background processes (e.g. Activities that the user exited from, but still have a running thread).
On my music streaming app, when music starts, I start a service (same process as the Activity) and add my app's Main Activity to the Notification area. When the user stops the music, I stop the service and remove the app from the notification area. You'll likely notice very similar behavior between the NPR App, Spotify, i-heart-radio, and others.
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.
im currently developing an app which plays the steam audio using MediaPlayer class. And i'd declare its main (Player) activity as SingleTop. Also on button "Back" it does moveTaskToBack(true) which acts the same as button Home does. So it just stays and plays on background and if user wants to see the gui he just starts the app once again (which is less convenient) or he clicks the special app's notify. Exit provided via menu.
but what are the benefits of using service instead of activity in such case? Definitely it would be more complex to develop, i have to say. Even instantiating the GUI while "on background" will take much more time, i'm afraid.
From the Android Documentation:
Activities
An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails.
Services
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.
also
Once started, a service can run in the background indefinitely, even if the component that started it is destroyed.
The Android OS can destroy your Activity if it runs out of resources, but it won't destroy the service.
EDIT: you should use startForeground() to ensure your Service won't be killed in situations where the resources are low. From the docs:
Make this service run in the foreground, supplying the ongoing notification to be shown to the user while in this state. By default services are background, meaning that if the system needs to kill them to reclaim more memory (such as to display a large page in a web browser), they can be killed without too much harm. You can set this flag if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.