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.
Related
A client of mine is requesting for a very specific functionality, to keep the application always active, even after the user force kills it. He wants to ensure that the users have the application active at any time while using the device on which it is installed (the devices are managed in a constrained environment).
I've done some research on it, and already enabled background services for sending the user's location, but if they force kill the app then we are unable to send locations to the server. We've seen other apps do it, but wonder how they do it.
According to https://stackoverflow.com/a/34573169/640907 it should be possible in Android. We also found https://ssaurel.medium.com/how-to-auto-restart-an-android-application-after-a-crash-or-a-force-close-error-1a361677c0ce but I don't think this will work for our use-case, as the user can close the application without "force kill" aswell..
Anyone knows how to achieve this for a Flutter application?
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 an Android app using the CastCompanionLibrary v2.9.1, modified to use play-services-cast:10.0.1 (just a simple change to the gradle dependencies).
Short version: The app is attempting to automatically connect to the ChromeCast device, without user interaction.
Long version:
Since updating the CCL library to use play services 10.0.1, I've had several users mention that the app is automatically connecting/casting to ChromeCast without user interaction.
Some users have said they're not using the app, then they connect to WiFi, and the app automatically attempts to cast. Others have said they are using the app, they don't press the ChromeCast button, and the app begins casting.
--
I'm having trouble figuring out where to look for potential changes to the ChromeCast APIs which might explain what's going on. I'm also not sure whether this issue is only occurring for my app, or for many other ChromeCast enabled apps. Lastly, I'm not able to reproduce this issue on my own ChromeCast device.
Any help would be appreciated.
I had not seen or heard this before, so here are some pointers for you to do further investigation to see what can be the cause. CCL has a (sticky) service called ReconnectionService that is responsible to perform reconnection attempts when you lose wifi and later gain it back. The wifi scenario you had mentioned resembles this so I would suggest to start from there. In order to only reconnect when it makes sense, it gets the time length of the content that is playing and only makes such attempts for that period of time; i.e. if you start playing a content that is for 1 hr and then you leave your phone on the table and pick it up after 2 hrs, it notices that the last movie before it fell sleep was for 1 hr so it won't make any attempt to reconnect (see handleTermination() in that same class). For live-stream that doesn't have a clear content duration, CCL uses a default of 2hrs but allows apps to modify that by calling VideoCastManager.setLiveStreamDuration(duration_in_seconds) method. Finally, the whole reconnection relies on a few factors: it saves the route-id of the last connection, along with the session ID. So if needed, you can clear any of these and then it won't try to reconnect for that particular session (in case you want to keep reconnection for some and disable on some other). Hope these help to troubleshoot the issue.
So it turns out there's a bug in Android Support Library 25.1.0 which was causing this issue.
https://code.google.com/p/google-cast-sdk/issues/detail?id=1105
Which is now marked as 'fixed internally'.
Also related:
https://code.google.com/p/android/issues/detail?id=232326
I've seen some "app locking" solutions in the Google Play store and I was wondering how those apps work. I'd like to build something similar.
I realize that this might require some special permission or maybe request the app to be added as device administrator.
Is there some broadcast that is triggered just before an app is launched that I can intercept and do some action (e.g. launch an activity that will request the user to fill a password)? I've read some lengthy discussions how this is not a good idea and the only idea is to have a background service that will continuously poll the running processes and check for changes, but I think retrieving this list every second and checking it for chances is not good for the battery and I think other app locking apps out there must be using a different approch.
If possible, without the need for a rooted phone.
I have an android app that is published in the Google Play Store. The Google Play Store app is how end-users install updates. I realize it's up to the user's discretion to turn on auto-updates, so this feature may or may not be turned on with any given phone.
My app runs a foreground service with an icon in the notification bar when it's running. During testing of the auto-update procedure, I noticed that if the service is running and the app updates itself, the service is shutdown (which is to be expected since new code is being installed).
However, I would like to avoid this if at all possible. What I would like to happen is find a way to detect when auto-update tries to update my app. If the service is running, I'd like to deny updates until the service finishes it's work and shuts down.
So is there any way to detect when the google play store attempts to update your app, and if so, is there a way to block the update until you determine your app is in a safe state to shutdown?
Unfortunately, I don't think there is a way to detect when the Play Store attempts to update your app, unless you have a second app to listen for this event. And even if you have a way to detect this, I don't think you can cancel the update.
Maybe it would be an idea for you to transfer the work you are doing to your second app while the first one is being updated. However, I needn't say that this sounds like a very hacky solution.
You should focus on saving your state and continuing from where you left after the application is updated and started.