I couldn't find any good application for streaming MP3s from a URL that can run in the background that meets my requirements so I decided to write one myself. It turns out its incredibly easy to stream an MP3 with the native MediaPlayer if you're running Froyo or better, and I am.
But my problem is if I switch applications and try to keep the stream going (some of them last 2-4 hours) and play a game or something while i'm listening to it, it sometimes just dies. I'm not sure exactly what the problem is, my guess is that the Android system decided it was OK to kill that process... but it wasn't.
So is there something I can do to make it kill other processes if resources are needed instead of my streaming mp3 app?
What I have tried:
android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_AUDIO);
But it's no good.
You need to make the service a foreground service, if you haven't already. Foreground services have to display an icon in the notification bar, and the Android system will not kill them unless under extreme memory pressure.
Check out the documents for startForeground()
I found that after my Droid Incredible was updated to Gingerbread (2.3.4) all of a sudden it works. I made no changes at all, it just doesn't die in Gingerbread like it did in Froyo. I know there were media player improvements in Gingerbread so I'm going to have to assume there was a bug in Froyo that was fixed in Gingerbread.
As far as i know, a program can't be running forever, at some point the OS will kill it. But what you can try is to have a service and make it generate notifications once in a while with useful information. Then, start the activity again.
This is due to an activity Lifecycle. The OS might kill your app if it need memory. You might have to consider a service
I have had problems with memory management in my Android phone, which terminated processes like you described. You may consider installing a program like Android Booster to monitor available memory and close programs that are using too much memory, so that the programs you would like to keep open have enough memory to run.
Related
Does android somehow keep track of which apps are/were running and if so when it was in foreground or background, etc?
I already had a look at adb logcat, which gives a rather overwhelming amount of data and I'm not quite sure if I actually will be able to deduce what was started when, but that might be possible.
Seeing how that log disappears after a while and does not survive reboots, I was curious if I'm maybe there might other places where android keeps information about running apps. For instance a colleague mentioned that iOS running apps can usually be deduced from the automatic screenshots it takes for app switching.
I have almost the same issue as where described here, answer in this post doesn't help me, I release my equalizer immediately after setting band levels to it. It works perfect on my 4.0.4 device, it works great on friend's 2.3.5 device, it crashes on a little percent of devices and it doesn't matter which version of android is running on these devices.
So there is error on
Equalizer mEqualizer = new Equalizer(0, mediaPlayer.getAudioSessionId());
java.lang.UnsupportedOperationException: Effect library not loaded
at android.media.audiofx.AudioEffect.<init>(AudioEffect.java:355)
at android.media.audiofx.Equalizer.<init>(Equalizer.java:149)
I have no idea how to solve this, any suggestions?
Make sure that you reboot the device and test it again with the release() after using the equalizer, it worked for me after 2 days of searching for clues.
From the documentation, you have to call release() on an Equalizer, MediaPlayer, Visualizer, etc for a graceful exit, or you will see this error when restarting the app. The only remedy then is to reboot, as previously mentioned in this thread.
This is where the Android application lifecycle makes things a little difficult, since apps are never supposed to exit (just pause and resume), unless absolutely required by the OS for memory reasons, or a reboot occurs. Your app onDestroy() method is called in both cases.
You can put the release() in onDestroy(), and that would satisfy the Android lifecycle for deployed apps. Your users would not see this error.
In development however there is a problem: IDEs like Eclipse (which is actually a framework for building IDEs, and not meant to be an IDE itself...) will kill the app process instead of sending it a destroy message. This violates the lifecycle and release() is not called.
This is also why you should never call System.exit(). It violates the lifecycle at the risk of ungraceful exits exactly like this.
So your process was exiting ungracefully. Only happens in development, not deployment. One remedy is to not use the device window in eclipse to stop processes. It is not a stop, but a kill.
Eclipse also kills (lifecycle violation) the process ungracefully when you Run an app project while there is already an instance running.
As the doctor said, if it hurts, don't do it: instead use the debugger which sends actual lifecycle messages to the app.
This depends on the build of Android that is loaded on the device.
This log means that there is no library to implements the AudioEffect feature.
I m afraid there is no solution for this, rather then importing into your project some third party audio effect library
I am writing an alarm program for android and am very happy with it so far. But I have a big concern about how to make sure it keeps running constantly. I.e. I don't want the OS to kill it to free up memory (I'd like the OS to kill other apps first) and I want to ensure that the program starts up again if the user powers down and up again. How can I achieve this?
Simple: You make sure that it doesn't run constantly. You're not supposed to. Not even with a service. There is a reason Android is trying to kill your process, you shouldn't try to work around it. If you're working on an alarm program, better take a look at AlarmManager instead.
I'm trying to develop an app that would normally be considered to be malware, but the customer's demands are very specific and logical. We have around 50-100 cheapset Android phones that are bolted down, plugged in, and the app is supposed to send some of the sensor data via tcp to a remote server. It sounds simple enough, but there are two features that I struggle with (since I'm not an experienced Android developer, and have never rooted a phone):
#1 The app should be always on. If it crashes, server should get the error report (stack trace), and the app should be restarted after 10 minutes one more time before giving up. Also, the OS could theoretically kill the app (although I did my best to minimize the memory usage). I'd like to somehow handle that as well.
#2 It would be great if the app could be remotely updated, or auto-updated, with no user interaction whatsoever (since there is no conventional user).
To implement #1, I see no other solution than to root the phone (AlarmsManager doesn't seem to work as I expected, and adding another application to take care of the first one just feels wrong). Is there anything I'm missing?
I don't know how to approach implementing feature #2 at all. If I put the app on the market and check the "keep this application always up to date" checkbox while installing it, will that work? I fear that the auto-update would not occur while the service is running, and even if it did, that the OS would not restart the service after installing the update (unless feature #1 is implemented). If I programatically download the latest .apk and open it, I still need the user to click the "Install" button. I'm even considering implementing the updateable part in some scripting language.
Is there a solution to these problems within the limits of Android API?
EDIT: Thank you all for your answers, you've been very helpful. It seems that the only way to make Android behave as a non-user piece of hardware is to root it. That's the only way to do silent auto-updates. Always on can then be implemented by enabling cron (AlarmManager apparently doesn't fire the event in case of service termination via crash, but it could be used by another trivial, non-crashable service to keep the first one running).
For #1 you can use an foreground service. I don't know how often you need to get sensor data, but what's the problem with AlarmManager? I don't see how rooting could help with #1 though. You can't really do #2 without rooting or building your firmware. If you install your app as a system app (in /system/app) you can use a hidden PackageManager to silently install the new version. Using Market/Play autoupdate should work as well, but you have no way to control the update schedule. And, yes, it won't restart your service, but if you use AlaramManager, this shouldn't be a issue.
All in all, stock Android is not exactly an embedded system that gives you full control, so depending on how much time/effort you are willing to spend, you might want to customize it somewhat (or find a custom ROM that gets close to your requirements).
Re: question #2, there are a few open-source (licensed under the Apache Software License 2.0) options you may check and see how it works.
https://github.com/lazydroid/auto-update-apk-client is the android client for the auto update service (i'm affiliated with), which is small, easy to implement and supports silent updates on rooted devices.
https://github.com/commonsguy/cwac-updater is written by Mark Murphy, however it might require you to run your own update server and I'm not sure about silent updates.
I've seen that if you kill some process, it restarts immediately and keep running. How this implemented? How to inform system that my service should not be killed and if that happened - restart it.
Android just does it. As an OS, Android is specifically designed to run with ram full at all times. So if you kill, or an app force closes it will, if their is room in ram for it be restarted by Android to fill the ram back up.
It does this because even the "fastest" phones are snails to even the most average of desktops and keeping as many programs that you use loaded in ram as possible enables it to simply "resume" the program instead of having to go through the slooooow, time wasting process of having to reload it back into ram and then running it from the beginning.
Android kernels have their own task manager. This means that it will be more efficient than any app-based task manager as it is run at the kernel level, and it should be left up to that task killer to decide when to free up memory or not free up memory. Let Android do what it was designed to do. Anything you do to try and force it to rerun a program or stop a program will, in the long run, slow it down more and possibly even cause stability issues.
However the short answer to your question is that there is no way to tell the "system" that your process should not be killed or to restart when it is closed. That is a choice made entirely by the kernel level task manager.
BTW, why would you want to? I ask this because I don't think you have thought this through very well. Remember, unlike IOS owners who are used to and expect total control over their device to be in the hands of Apple(for good or ill) Android owners expect, and will have control over their device. If you try to take that away from them, you will likely find most people uninstalling your service. And demanding their money back if you charge a fee for it.
I hope this has helped.
Not sure this is something that's good, but I've seen malware processes that have "buddy" processes that revive each other when one or more go down.
I hope whatever you're doing is ethical :-)