I have an app which is closing after some period of time. The app is consuming around 20MB of RAM. I do have more than 120MB ram still available. I am not sure if this is the OS behavior or some problem with my app. Even with app like Opera mini, after a while it restarts again. Is there a way to avoid this problem?
Problem with my app: I need to search the SD card for files with some specific extensions like mp3, jpg and some others and store it in local variables. When the app restarts again, it needs to do that work again. I need to avoid that. There are some app level settings which I am taking care using sharedPreferences. But the huge data is the problem.
Thx!
Rahul.
This is perfectly normal behavior. Android will terminate processes after a period of time running in the background. Generally speaking, there is no "problem" for most well-written apps, that save user data to persistent storage (files, database, SharedPreferences) as activities get stopped, etc.
If you feel that you have a process that should live longer, please edit your question to provide a justification for this claim, as that may help us to provide recommendations on how to organize your app.
Related
I am getting a message like "your application restarted 9 times in 5 minutes()", when I tried to clean Junk Files using "Clean Master" application.
Please find the screenshot for this issue. I am not able to figure out why this message is coming. Any idea on this???
These apps may have once been useful but the Android has progressed far enough that they are now outdated, unnecessary and rather harmful.
On Windows, you want to keep as much RAM as possible as you can so that programs have enough room to operate. When RAM fills up, Windows is forced to start using hard drive space as virtual RAM and hard drives are much slower than physical RAM.
This is not true for Android.
Android’s operating system has its own native handler for assigning RAM to apps and making sure that all of it is being used in the most optimal way. In fact, Android purposely tries to keep apps loaded into RAM for better performance. RAM is fast, remember? On mobile devices, every bit of speed is critical for a good user experience, so keeping apps in RAM is actually a good thing.
Not only does Android handle RAM assignment, but it also keeps track of background apps so they don’t use up unnecessary processor resources. There’s no noticeable performance hit for leaving apps loaded in RAM.
App killers, memory boosters, performance enhancers, etc all claim wiping memory will speed up the phone. With current versions of Android, that's simply not true. It's actually the opposite. What will happen is the task killer app kills other apps which use resources to process. Then the OS restarts those, or other apps to fill the memory again, which takes even more resources. The task killer app kills again and the process repeats over and over. So in reality, those kinds of apps reduce performance and increase battery usage by restarting apps again and again. Remember, those dormant apps don't consume any additional battery or CPU in the first place.
I am currently working on an app that runs on iOS and Android. The core of the app is written in C++ and allocates over time more and more memory. The thing is I want at the same time to be able to use as much memory as possible and ensure the stability of the app.
Of course, to do that I would need to know how much memory I can still use. This way, if I see after a while that I am going to need more than it is available, I could stop allocating instead of getting killed by the OS or crashing.
The problem is, after reading and trying different solutions, my feeling is the information that you dynamically get is not reliable enough. For instance, on iOS:
[NSProcessInfo processInfo].physicalMemory
This is one of the typical examples / answers I have read that seems not to be reliable. It seems that you cannot get enough information dynamically to make sure that you still have enough memory, because the OS will at some point kill your app if it uses too much memory and sends warnings before. But it also can kill other apps in between, so stopping when I receive the first one seems not to be an optimal solution.
After reading a lot of posts, I am a bit confused on the topic. Is there a way to know dynamically and reliably how much memory is left for my app on iOS/Android ? Or memory management from these OS is too unpredictable for that ?
Thanks for the help !
By design, you're prohibited by the operating system from ever using up all the physical memory on the device; what's more, the requirements of the operating system and the other apps running on it mean that the amount of memory your app can comfortably use will vary over time.
Therefore asking how much memory you have left to use isn't really sensible. You should design your app to use as little memory as possible, and then optimize until you use less than that.
Be aggressive about caching things out to disk.
Listen to the OS-provided notifications that your memory is under pressure.
Design your app in such a way that you can restore its last UI state from fresh launch: app launches and task switches are presented to the user the same way, and they won't and shouldn't need to know the difference.
If you do use more and more memory, the OS will try and terminate other apps to make room for yours. That means, bye bye Facebook, bye bye Twitter, bye bye Mail, bye bye Contacts. Your users will notice, and they will choose to launch your app less often, or review it less favorably, as a result.
I am developing an Android application that places a high priority on protecting the user's data, to the point of storing nothing in persistent memory on the local device.
To further protect user data, we want to make a web-service call to our server whenever someone attempts to take a screenshot of the active application.
Solutions that I have seen so far include this snippet intended to prevent the screenshot from being taken and throwing a screenshot failure message in a Toast at the user. Another approach I was considering was listening for the combination of Volume Down and Power button that some devices use to take screenshots (though devices such as the Samsung S4 deviate from this method). My last resort was going to use a FileObserver in the location of the screenshot Gallery for changes while the app is running, but that also seems like a sub-optimal solution and introduces a Permission request that I'd rather not have. I also can't be sure of the file destination for the images.
I believe the Snapchat app is able to alert participants when a remote user attempts to take a screenshot. Do you have any suggestions on how this feature might be implemented, short of rooting the device? Non-official methods are welcome as well.
FLAG_SECURE is probably the best way to avoid screenshots in a window, but as some commenters say here it has some workarounds.
Maybe this answer solves the question about how do they do it in Snapchat to detect when a screenshot has been taken.
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.
We are currently developing an Android app that is a fitness-tracker application. It runs constantly in the background, and it works fine on most devices, but we've been having issues with the application dying completely on some Samsung devices. After some investigation, it seems like some Samsung devices has a completely custom "App Optimisation" feature (http://forums.androidcentral.com/samsung-galaxy-s6/599408-app-optimisation-after-updating.html), which is basically a (very) primitive version of the Doze feature that exists in later versions of Android which basically just murders apps if they haven't been used for three days.
As this app is more or less only doing logging, and doesn't open the activity, it presents a big problem for us, because this feature is pre-enabled on many Samsung devices. The problem is solved by using a foreground service, but that is a sledgehammer of a solution that requires disturbing the user with a constant notification, and we really don't need the app to be in the foreground - we are fine with the normal power management of Android.
The Samsung App Optimisation feature clearly states that it will "optimise" apps if they have not been used for three days. Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
Side-rant: In my opinion, this is a badly implemented feature that makes development on Android more hostile. Besides our use case, it will any messenger applications break. If it were not for the fact that Facebook Messenger and Whatsapp are hard-wired to be exempt for the app, users would be going crazy because it would be breaking their experiences.
I've owned (and currently own) Samsung devices, so I know a little as to how it works from the user's point of view. The technical specifications and how it works on the inside is an entirely separate issue, and one I can't answer.
The system can detect if you open an app. Samsung uses that in their app optimization, and will save power on apps that haven't been used in over three days. It is a terrible system though.
It ignores background-processes that may be critical to apps, and even if it is an app you actively use, like a fitness tracker, it will have issues. To quote what it says inside the app optimization-list:
"To save battery power, apps that haven't been used for more than 3 days will be designated to save power. Apps designated to save power may not show notifications"
(Rough translation from Norwegian, originally taken from an S6 running Android 6)
Therefore, apps that have been manually, or automatically set (3 days of no use) may give various issues with background processes. But remember that the user can set any app to never save battery, and ignoring the automatic setting. So with this in mind, let's consider possible solutions.
There is one scenario where you do not need to worry about the app and app optimization: When app optimization is disabled entirely.
Looking aside that, there is really only two things you can do:
Ask users on Samsung to disable battery optimization for your app to prevent issues
As #MinaSamy suggested (in their now deleted answer), SyncAdapter and having a periodic synchronization. Note that I haven't tested this, so I don't know whether it works or not.
And there's also a third option, which really isn't a solution, but you can ignore it and gamble on app optimization being disabled, or just not care about it at all.
Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
As far as I know, unless Samsung added some safeguards against accidental opening or added some kind of minimum activity requirement, opening is enough. It appears to be a "stupid" feature, which runs on hard-coded rules rather than a dynamic system that actually detects app use and sets power saving relative to that. It's "easy to enable", but fortunately easy to disable as well.
Meaning you cannot trigger an event that will keep it alive (unless SyncAdapter does the trick)
And to make the facts clear, from #Neil's answer:
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
There kinda is. There are a total of four settings, three of which are app-specific, and it is stored in a database (or some other form of data storage). These four settings can be used, although extremely shallow, to alter the behavior of the app optimization:
Always optimize
Automatic optimization
Never optimize
Disable app optimization
The first three options are on a per-app basis, which means each app can have separate settings. Disabling app optimization is exactly what you'd expect: it disables the entire feature for all apps. If it's disabled entirely, nothing is optimized.
There's also a website listing ways of bypassing optimizations on a per-brand basis. The entry for Samsung is more or less what I've said: tell the user to manually disable optimization. There are no developer solutions.
In settings>device health>battery there's an option to "put unused apps to sleep". You can turn it off, or change the amount of time it takes, which is 3 days by default.
Sounds like that's your problem.
https://forums.androidcentral.com/samsung-galaxy-s10-s10-plus/964083-whats-disabling-some-my-apps-background.html
Is there a reason you can't add your service to the 'don't optimise' list?
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
Alternatively, if you detect you are installing on one of the devices, open the optimise activity page, and show a message saying "Don't optimise us!".
As a workaround, i implemented the SyncAdapter mechanism, using this link as a good starting point: https://github.com/bmeike/MiniSync
It doesn't work perfectly (for testing, in my app i write a log every 1h, and after 3 days, it starts not respecting this scheduling), but at least it doesn't stop after 3 days, without the need to put the app in ignored optimization mode.
UPDATE: After the update to android PIE, scheduling stopped again after 3 days.
On another device, same app with android Oreo, scheduling is working (even if not completely respected).
On Samsung phones, the culprit is this Sleep setting:
You have got to take your users to this system settings screen and ask them to turn the feature off.
In my opinion you should implement a 'Broadcast Receiver' that listens to a custom 'Intent' and this 'Intent' to be Broadcasted by the 'Service' from 'onDestroy()' method of the 'Service' because when the 'System' kill the 'Service' this method will be called definitely.
And when the 'Broadcast Receiver' receives the 'Intent' you should start the 'Service' again.
And to distinguish between you stopping the 'Service' or the 'System' stopping the 'Service' just use some 'booleans' stored in 'SharedPreferences' and then in the 'Broadcast Receiver' you decide whether to activate the 'Service' or not
we are fine with the normal power management of Android
Are you? From the Android docs
However, since the user is not directly aware of a background service, in that state it is considered a valid candidate to kill, and you should be prepared for this to happen. In particular, long-running services will be increasingly likely to kill and are guaranteed to be killed (and restarted if appropriate) if they remain started long enough.
Three days seems like it would fall under "long-running...guaranteed to be killed".
If the problem is not that your service is killed but that it isn't restarted, you could use the AlarmManager to regularly check the status of your service and restart, if necessary.