I'm testing a kiosk app that runs continuously. I have setup auto-updates in the Play Store and am trying to see when it updates. I left two tablets running for over 3 days, and only after they died and I restarted them did the updates occur. The app was not running on boot.
I tried to restart the devices during the 3 days to no avail and even the apps that weren't running didn't auto update so I know it's not because the app is running (my first assumption when doing research).
Looking online, I'm seeing a lot of people say that auto updates happen at random and only on wifi etc. I've had the tablet on wifi the entire time and let it charge over the first day to see if the power state changed anything.
Is there a way to test auto updating reliably? When does the Play Store do updates?
Related
I have 2 apps that require background location. One is for Golfing, and one is for Sailing. In sailing you probably dont have the phone connected. In Golf it continuously connects and disconnects.
So what I found out is that the Wear OS simulator behaves differently from the Galaxy watch 4. On the simulator I get an update each 3 seconds. Now on the Galaxy watch 4 I get an update each 3 minutes when location is turned off on the Phone. When the location is turned on on the phone then I get an update each 3 seconds.
I have asked permissions for ACCESS_FINE_LOCATION and ACCESS_BACKGROUND_LOCATION. Ambient Mode Support is ON
In my preferred situation I receive an GPS update each second while the watch screen is on or off. Now I already tried several options to achieve this but it isn't working. I'm now at a point to think that the Galaxy Watch 4 with Wear OS just limits the GPS when the screen is off no matter what. Though, there are many workout apps that need background GPS for distance speed calculations so I can't imagine it isn't simply possible.
In a ViewModel I started fusedLocationProviderClient.requestLocationUpdates
I get an update each second when the screen is on. when the screen is off, no updates
Starting a Service
update each 3 seconds when screen is on. no updates when screen is off.
Starting a service with broadcastreceiver:
location update each 3 seconds when screen is on and update each 3 minutes when the screen is off.
Start a service with an ongoing notification and ongoing activity
Same results as 3
Service with ongoing activity and wakelocks
Same results as 3
I could share my code, but my primary question is. Is it possible to achieve my desired result and is it possible. A bonus would be a method to force use the WAtch GPS since it is essential in Golf as your phone is often 20 yards/meters away and the distance to the flag needs to be way more precise than that.
After a day of many trial and error i found the cause.
In my situation I had my Samsung Watch 4 and an Emulator in Android Studio. The galaxy watch was used in the Galaxy Wear app and the Emulator was paired in the Google Wear app. This causes a Conflict. I removed the Google Wear app from my phone and it started to work as expected.
Another thing I noticed is that when you run a service, it gets killed 30 seconds after the screen goes out. But, when your watch is on a Charger, that doesn't happen. As I often develop with the watch on the charges because the WIFI ADB debugging and GPS consume a lot of battery.
I have an app which runs a background service overnight. It's triggered to run by an alarm clock app.
The app spends the night uploading data off the phone's external SD card onto Dropbox. It worked seamlessly on previous versions of Android but is not working on Pie. The background service is killed after running for about two hours every night. Interestingly, however, I've noticed that if I make a tiny change to my code, e.g. editing a string, and then run a debug, the app runs perfectly the next night but then on subsequent nights, goes back to being killed after two hours.
I've tried the following:
Using a foreground service with a persistent notification
Opening and closing an Activity after the app is opened so it's in the recent apps list
Making the app a device administrator
Disabling battery optimisations for the app
CPU and Wifi wakelocks
Running a thread with an infinite loop that uses root privileges to adjust the app's minfree values every five seconds
Disabling Pie's adaptive battery manager feature during the night
Despite all of these mechanisms, the app still gets killed. My theory is that there's some kind of artificial intelligent battery manager/performance optimiser on the phone that picks up that the app runs all night and decides to kill it in the future but then gets reset when I re-install the app.
I've tried everything and I still can't seem to find a solution. Can someone please point me in the right direction? I'm sure there's some root/reflection thing that I can do to fix this but I just don't know what it is!
I found the problem! Turns out my phone had a service called G3 which was killing the app to "save power". Apparently, this service is useless so I uninstalled it and the problem was solved instantly!
I used the following command:
adb shell pm uninstall --user 0 com.evenwell.powersaving.g3
adb shell pm uninstall --user 0 com.evenwell.powersaving.g3.overlay.base.s600ww
Pretty annoyed that this service took to killing an app that had root, administrator privileges and permission to avoid battery optimisations - how obvious do I have to make it that I want the app to stay alive?!
try job schedular
https://developer.android.com/reference/android/app/job/JobScheduler.html
https://developer.android.com/topic/performance/scheduling.html
use Alarm manager
https://developer.android.com/reference/android/app/AlarmManager.html
As one of the changes that Android 8.0 (API level 26) introduces to improve battery life, when your app enters the cached state, with no active components, the system releases any wakelocks that the app holds.
In addition, to improve device performance, the system limits certain behaviors by apps that are not running in the foreground. Specifically:
Apps that are running in the background now have limits on how freely they can access background services.
Apps cannot use their manifests to register for most implicit broadcasts (that is, broadcasts that are not targeted specifically at the app).
By default, these restrictions only apply to apps that target O. However, users can enable these restrictions for any app from the Settings screen, even if the app has not targetted O.
Nothing will work like job schedular or Alarm manager
Your problem will be only resolved by using WorkManager
We're currently running tests (that end in 2 weeks) with clients using an "older" version of our app.
The older app has a long-running scanner foreground service that will not restart on the MY_PACKAGE_UPDATE broadcast (wasn't implemented at the time). The new version of the app correctly handles this broadcast and restarts the scanning on MY_PACKAGE_UPDATE.
We need to roll out updates mid-test to fix a bug appearing on only some devices, and we are able to reach out to those specific users. The problem is that for any current users with auto-update turned on, their foreground scanning service will exit and not restart.
Am I correct that the MY_PACKAGE_UPDATE broadcast won't kick in yet? As in, it'll only begin working two updates from now?
Is there a way for me to turn off auto-updating for my app in the play store for all users?
I'm releasing a single app purpose that I update through google play store.
For those who do not know, a single app purpose is an app that is supposed to run alone on a device.
Therefore I give away the device the app, and prevent the users to use any other apps.
Anyway, I start the app automatically on boot. The devices reboot every day at 5 AM.
I've noticed that the google play store checks for updates when the device boots.
Unfortunately, it seems that the update won't perform while the app is opened.
To this I have 2 questions :
Is this odd behavior of update familiar to anybody (having the update not performing for the currently running apps)
How to solve this?
PS: I did think of updating the app versionCode on a third party server and if it's not up to date, close the app, let the update perform, then receive when the update is done performing to re-open the app.
But honestly, it feels like killing a fly with the bazooka.
I think you should depend on external server for this purpose.
App not being updated when running in foreground makes sense because Google play is not supposed to stop a running app which is necessary for updating it.
I recommend you to use Firebase cloud messaging service for the purpose. You can easily send data to the device using FCM.
I have a Bike computer app that logs data while the user is riding. I have had a user report an issue I had not considered. He was out for a long ride (100+ miles) but while out and logging data the app got updated via Google plays auto-update. This unfortunately killed off the app mid recording and the user lost data till they spotted what had happened and restarted the app.
Ideally I would like to be able to programmatic stop the auto-update happening while the app is data logging. All my research indicates that this is not possible possible but I may of missed something so dose anyone know of a way of doing this?
Given no solution the best I can do is advice the users to enable the update only over wifi option in the Play app which in this instance would of helped. Unfortunately one of the key points about my app is that it will log indoor sessions using ANT+ sensors so I have a good number of people using it with wifi active.
Edit
I managed to do the experiment to see what happens myself last night. I had an app going in the background data logging then pushed a new version to Google Play. Unfortunatly it was not picked up totaly automaticaly when I had to leave 10 hours latter but I opened up the play store app and it found the update it did not start updating automaticaly but I forced it. The act of downloading and installing the new version killed off what was in progress. It was already dead before I used the notification to go to the new version.
As you say yourself, you can't do that what you are asking for. You could hack your way around it by changing the permissions each time you update. The users will then be prompted about it in the regular way.
I'm not sure about the "life-cycle" for automatic updated apps that are running. But I read somewhere that is wasn't the re-install but the reopen of the app that crashed it. If that is the case you could set a flag indicating that the user is currently logging and then on restart just resume the logging. But again we need to know more about the inner workings of activities/apps which are running and get an automatic update (actually didn't think it could happen).
Edit
Based on your findings I'd say you have to handle the app is shut down in onDestroy etc. or/and make sure you save everything persistently. Then you might need to have 2 apps where 1 listens to the other being re installed and when that happens it starts it up again (there is an interesting discussion here). If you are targeting api >= 12 then the broadcast action ACTION_MY_PACKAGE_REPLACED might also have interest.