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.
Related
I am creating application that has endless ForegroundService for new android versions.
Problem is that ForegroundService always dies after some time no matter what.
Tried to do Battery optimization, Wake lock, creating new process for service, even creating JobScheduler that checks if Service still working, but that one also stops working after some time.
Tried to follow Google samples, Stackoverflow solutions and many others, nothing seems to work.
I also made some research on my banking app and some other apps that relies on services for notifying the user or tracking some activities, they also not working flawlessly like old times.
At the end I figure out that for some Vendor phones doing some extra setting Vendor specific setting helps, this link one of many examples to understand Slack Known issues with Android .
After this reading, I don't think that simple user should go somewhere in to deep phone setting to make app that he likes to work... In fact I think it is the worst practice....
Made some conclusion after researching that because of saving few battery percents Google and poorly made Vendors battery saving strategies on top making phones dump and not reliable....
Also these background restrictions making not possible to develop awesome pocket portable device features...
I mean I agree with ForegroundService idea for long running task instead of simple Service in background that might be malware, spying or whatever that user does know nothing about it. Also agree that User is notified about high power usage, but randomly killing everything is same as killing the idea of smart device.
Please tell me that I am wrong about everything and give me a solution :)
I'm using location & activity recognition features of android. Used for realtime location tracking. Currently using the latest ConnectionLess APIs. I have encountered the following problem:
After starting the location, activity services, once in a while, the battery starts to get drained. The behavior is pretty strange as the entire drain is showed under Google Play Services. The drain persists even if the app is stopped, killed, etc. To my surprise, the drain persisted even when the app was uninstalled and it took a couple of full battery re-charges to come out of the situation.
I'm more or less sure that the drain is triggered by my app as multiple devices have recorded the issue and these devices are from different manufacturers and across multiple android OS versions. In ADB shell, I find com.google.android.gms taking up 126% CPU permanently as seen below:
Next, I listed all the threads under that process. Result attached below:
As seen there's one thread, CastSocketMulti running. All other threads are sleeping.Didn't get much on castSocketMulti other than some basic information like it is related to casting in android, etc. We aren't using anything related to casting in our app.
After, killing the process, the drain stops.
Note: I found same question here, however unanswered.
Edit: Every time the battery drain happens, as above, com.google.android.gmsis listed as the number one process taking 100%+ CPU and the castSocketMulti, the only thread of that process in R status
Update: I have opened an issue here.
Pls leave a star so that it may go high on priority
I have found the exact same thing here on a OnePlus 3. I'm not rooted and can't kill the process, but using adb to clear the cache of com.google.android.gms makes the process crash and alleviates the problem for a few days.
Do you use Android Auto or Android Pay? It seems to happen more frequently when I use those two apps in particular.
OK, Google claims to have fixed the issue and they have marked the issue as 'Fixed'. Details here
I am developing an android application in which i need to perform an action when other apps are closed / force stopped. This detection has to be made from a service which is been running in the background once started. Making the service to run continuously is not a problem but making detection when other apps are closed is the problem. Please do anyone have any solution.....
I don't believe it's possible to detect when an app is force stopped. Even the app being stopped doesn't get that information. You can detect if an app is currently closed by using the BroadcastReceiver. Here's a pretty decent tutorial on using that: http://saigeethamn.blogspot.com/2009/10/android-developer-tutorial-part-11.html
I am not aware of any official way in which Android allows apps to listen in on when other apps are forced to close. So you’d have to poke around under the hood.
Disclaimer: Doing so is unsupported. While just reading information is unlikely to cause any harm, there’s no guarantee that it will work universally. If you get it to work on your particular build of Android, may still fail on different builds. Also, Google keeps locking down features in Android with every new version, so there’s a high likelihood a future update may break things.
I haven’t actually tried any of the below, hence there is a possibility they will fail to produce the expected result.
That being said, here are a few things you can try. You may need to combine them to get something useful out of them.
Processes
Since Android is based on a (somewhat) modified Linux kernel, it generally supports most Unix mechanisms for working with processes.
Apps are launched by a process called zygote. A quick run of ps on an Android device shows me that all user apps (as well as the higher-level system apps) seem to be children of the zygote process. Thus you could get a list of all processes, find the PID for zygote and grab all its child processes.
Then you might be able to waitpid() on each process and examine its exit status. You may want to experiment around with this a bit and see if the exit codes tell you anything about how the process ended.
Also take a look at ptrace(). You might be able to monitor zygote directly with an option such as PTRACE_O_TRACEFORK, which should basically notify you each time a new app is launched, allowing you to monitor its PID as well.
Downside: You probably need to be root to do any of this. Linux doesn’t let users see other users’ processes (which is an essential security feature), and Android harnesses (or abuses) the user model by running each app with a separate Linux UID.
Logcat
Looking at various logcat apps (e.g. aLogcat), you might be able to monitor the logcat for events like this:
12-26 10:01:27.670 I/ActivityManager( 774): Process org.openbmap (pid 21647) has died.
There are a few events that may occur when an app crashes—ActivityManager will tell you when an app has died, or you might watch for unhandled exceptions.
Note: While this doesn’t seem to require root (aLogcat works fine without), it may not work under all conditions. I have seen devices where aLogcat sees next to no entries, though I didn't investigate why. In those cases, the above approach would not work as it depends on being able to read the logcat.
I have written an android app that generates a strange exception on the LG-Phone I have just started testing on. In DDMS the tag is "ISP_LOG_MW_DEBUG" and the text is "AMI_IsWindowSearch()." It is generated about 10 times per second while the app is running. It doesn't seem to interfere with the program itself, but I would rather not have this error. but I can not find any information on this on the web.
If a click the home button (the app continues running in the background) and start the app again (new UI, with the old services) the amount of these messages increases each time. So it is reasonable to assume that they are generated by something in the UI.
Has anybody experienced this error or has any idea how to avoid it?
Real devices can sometimes make a lot of noise. Sometimes the vendors just leave a lot of debugging turned on. If your app is not crashing, or showing performance issues, I would say it's safe to ignore.
Also, try with another device, or try with the emulator. If you don't see those errors with another device or the emulator, I think it's safe to say the vendor developers of the the LG device are just lazy and didn't turn off all their debugging like a good developer should. :D
db
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.