I want to receive time tick in a widget, and tried the code in this link, and it works great on my kindle fire which runs a custom ROM of Android API level 15, but sometimes the time is wrong on my phone which runs Android 4.2 API level 17.
my confusion is the same as a comment below the article
This is completely unreliable. Android will terminate your process whenever it wants after the onUpdate() method returns, causing the BroadcastReceiver and Application to both vanish.
can anyone explain or testify the code?
I want to receive time tick in a widget
That is not possible in a reliable fashion.
and tried the code in this link
That code is completely unreliable, as I noted in a comment on the blog post.
it works great on my kindle fire which runs a custom ROM of Android API level 15
You have not run your app for long enough. It will fail on your Kindle Fire as well.
but sometimes the time is wrong on my phone which runs Android 4.2 API level 17
It is possible that Android 4.2 is more aggressive about terminating processes with no active components, which is why it is failing faster for you on your phone. However, it is guaranteed to fail, for the reason I outlined in my comment on the blog post and that you quoted in your question.
Android apps run as OS processes, as programs do in most modern operating systems. Android will terminate processes as needed to reclaim RAM to use for other processes. Android will eventually terminate the process for your app, at which time your registered receiver evaporates.
In the meantime, if onUpdate() gets called multiple times, you will register multiple receivers for the broadcast, each additional receiver adding that much more overhead.
Related
Recently I have discovered that about 2 months ago there was released Android 11 update for Samsung devices.
Samsung has in this version of OS decided to really strictly suspend the apps/services running in the background (more info)
So e.g. when app I am working on goes to background and phone is locked, all BT communication is almost immediately suspended. When I unlock the screen, in that exact moment all threads are not suspended anymore and execution continues.
OS therefore completely ignores the foreground service mechanism.
Official documentation
Also when I try to add my app to the list of "Never sleeping apps" (some alternative to battery optimization whitelist on Android 11) - app is still getting suspended + this whitelisting mechanism appears to be unstable and even when I add my app to the whitelist, app disappears from the list after few hours.
My questions:
Have you seen similar issues on Android 11 too ? What helped to resolve the issue?
Is this only Samsung specific issue or even Pixel devices do the same optimization (ignoring foreground service and whitelist)?
Thanks for any input.
sadly this is a huge and common problem and my repsonse will probably not fix it for you, but give you some more insights and possible work-arounds. Have a look at dontkillmyapp.com.
Especially dontkillmyapp.com/samsung:
On Android 11 Samsung will prevent apps work in background by default unless you exclude apps from battery optimizations. This is a severe divergence from standard Android process management policies.
Yes, this is a long way to go! Devs cannot ask for it automatically as they risk being kicked out from Play Store due to policy violations.
Also I can highly recommend very insightful the fun talk fron Droidcon Berlin 2021.
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 building an application which needs to determine the time an app has been running, so I can show the user statistics of the apps he / she uses. I found multiple solutions online but al those have their flaws.
Here are the two best options I found:
Using a polling mechanism with a service. This solution seems battery inefficient and depends on a deprecated method (since API level 21):
getRunningTasks(int maximum)
Using the new "App usage statistics" introduces in Lollipop, but this solution will only work with devices running android > 5.0. But I want to support older devices as well.
I have also searched for a intent firing when a app starts or stops but there seems to be none (see Summary). This post confirms that. Also I found a class: ActivityLifecycleCallbacks which gets callbacks when a activity changes it state. But this is only for internal (read inside your own application) use.
So my idea is to use a service to poll the current foreground app on devices which are running version other than lollipop and use the new API on devices running lollipop or greater. But is this "service" idea the best option because as I said before it seems battery inefficient? Maybe there are better options?
Faas
1st option is definitely bad as it is deprecated.
I would rather suggest you to use android.app.usage
What the app you cite is probably doing is wasting a lot of CPU time, RAM, and battery life, polling ActivityManager continuously.
Bear in mind that what you propose to track, if you plan on having anyone other than the user access it, borders on privacy violations of the type that got CarrierIQ in a fair amount of trouble.
I have a somewhat unusual Android app in the Play Store that's running on dedicated devices 24/7 (it collects sensor data, it's not meant to run on phones used for anything else). I would like the app to auto-update without user interaction, but that never seems to happen. Why could this be?
Some more background:
Auto-update is explicitly turned on for the app on the devices.
Other apps do seem to auto-update.
The app stops and restarts itself every 12 hours; mostly to whack the app out of any weird state it might get into and clear memory, but I was also hoping this would give it a chance to auto-update. There is a 10 second delay until the app restarts.
The devices are mostly old phones (HTC Desire C) running Android 4.0.4
This is fairly hard and time-consuming to test so any experiences shared with similar requirements could be helpful.
Make sure the port 5228, TCP and UDP, is not blocked by a firewall per https://support.google.com/googleplay/answer/2651367?hl=en
We've had a similar problem for years. Our apps run on school deployed devices. Whenever we push an update, it reaches may be 10% of devices within 24 hours, the rest seem to "hang". It takes about a week for another 30% of devices to get the update, while the remaining %60 never get it. There is no difference in settings across devices. All set to auto-update of course.
The way we "solved it" is our app is checking if the market has a newer version (there are libraries for doing it, but we have own server responding yes/no). If there is a newer version of the app, we invoke the intent to open Google Play with the app's page. The user has to manually click "Update" at that point.
If there was a native or cleaner way to push the updates we'd love to hear, even at this point in the game. Bothering users to update is not ideal.
This is a long shot: Maybe there was any change in the apps required permissions?
That would require manual updating (even if auto-update is on). Maybe you installed the app first in those old devices, then changed the permissions, then installed the app in new devices, then updated the app. That would make the autoupdate system work in the newer devices, and not work in the older ones.
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.