After a lot of research, I got to a conclusion that uninstalls can't be tracked as "Package Removed" action is not broadcasted to all the apps except the one getting uninstalled.
And then I found a way of tracking uninstalls. I saved all uninstall user information by Sending a GCM and getting "Not Registered" error in the response(GCM gives "Not Registered" error for devices with the app uninstalled).
So now, when I installed Opera Max app and uninstalled it, it opened a webpage asking for "Uninstall Survey". How could they have done that?
See these slides from Droidcon 2015 where some guys reverse-engineered how Opera Max is doing that, and see this GitHub repository for some example code.
I can't repro this behaviour when I uninstall Opera Max, but I believe their technique is along the following lines:
they somehow register an event handler that will send an Intent if and when the directory that the app was installed to disappears
that event handler survives the uninstallation of the app
when the directory disappears the intent fires - of course they can't run their own code now (since it has been uninstalled), but they can direct you to a webpage in whatever browser is in place
I didn't have any other Opera apps installed when I tried this - if you have a second app that you also control that has not been uninstalled, then it's easy for each app to monitor the uninstallation of the other one.
I was running on Lollipop - perhaps recent versions of Android have closed what certainly feels like a security hole.
Related
all day I already despair of a waking up system for my VoIP app. I must have already read over 100 articles and documentation about it, however I have not found a solution that works for me.
Use case:
My app is running in the background. That means the home button was pressed
after my app was started and the device is in the home screen. As soon as a notification arrives, the app is supposed to open again on a certain route because a call is coming in.
In the lock screen I managed this pretty easily with flutter_local_notifications and within the app it was of course no problem either.
Note:
Only Android is important, the rest can be neglected
Android version 10+
Flutter version 2+
I appreciate any input on how to solve my problem and have a good week.
Kind regards,
Shiro
I'm having a problem receiving push notifications to an Android Chrome PWA when no Chrome apps are running. I can reproduce this with 3 different public web-push examples. The first question is should a web-push example work the same as a PWA with web-push? That is, should a web push on Android be able to be received and display a notification even if the browser is not running. Docs seem to say yes. Why does the test below not confirm this.
Problem Description
The problem does not affect Firefox. There are other posts that have attributed similar behavior to the payload of the message (data and/or notification) or the battery optimization settings. Altering these variables doesn't seem to improve my situation. Here's a method for reproducing the problem using one of the online examples (Thanks to Carlos for pulling this together..see code here).
Reproduction Steps
Open up Carlos demo on your Android phone. Accept the notification permissions and ensure that you can send yourself a notification.
Open up the same page on another machine. Ensure that you can send your phone a push notification using the "Send to all subscribers immediatelly"[sic] function.
Kill all the Chrome apps on your android device. To be on the safe side, kill all your running apps cause I've found it not obvious what's using chrome and I think this has confused a lot of previous posts/answers.
Repeat step 2 on the second machine. You should not get the notification on Chrome.
Once you're convinced the message is not coming, open any Chrome app. After a few seconds, you should receive the notifications.
Repeat all of the above with Firefox on Android and you will get the notification in step 4.
You can run a similar tests here or here.
There are several bugs related to this issue on Chrome. The problem is resolved in Chrome Dev 74 which is due to be stable on Apr 23, 2019.
I'm developing a kiosk type application, running on a rooted device.
One feature of the app is that you must be able to download new versions of the app via wifi. However after running sudo commands to uninstall the app & reinstall the new one, we see the message 'unfortunately app has stopped'.
I'm trying to find a work around. The client does not want this dialog to be shown.
I thought of creating a second application to host on the device in order to display whilst updating and to close again after, but even if the other app is in the background, we would still be able to see the dialog which is against the clients wishes.
Any suggestions?
I doubt that the solution you thought of will work.
You receive the message saying unfortunately app has stopped because it is getting uninstalled while it is still running either in the background or not it doesn't matter.
What I would imagine could be a solution is sending out a command to quit the application you could use force-stop for this.
Take a look at these posts they might help you out
Stopping an Android app from console
Force Close an app programmatically
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.
Is there a way to get a system notification when an app has been uninstalled?
I would like to maintain a table of all clients' info currently using my app. However, that seems impossible if there is no way to detect this event.
The first solution I can think of is to have an always running service in the background listening for android.intent.action.PACKAGE_REMOVED. But then would that service be killed once the uninstallation process has ended, or would it be stopped just before the process has kicked off? Also even if this is a solution it's has the potential to put off a lot of people when they realise that part of the app is running in the background.
Any suggestions? Thanks!
You could simply do it the other way round and maintain a table of users actively using your app. Just call a webservice at a point in the program that show it is active. If an app isn't used for a certain time mark it as inactive.
The documentation for the PACKAGE_REMOVED action says the following:
The package that is being uninstalled does not receive this Intent.
So you can monitor for other applications being uninstalled but not your own.
So you'll probably need track who is still using your application, not who has stopped using it. If you don't want the overhead of having your own server to do this you could use a free service like Flurry.
From Android document, the app uninstalled by user can't not get
Intent.ACTION_PACKAGE_REMOVE
But we can use other method to implement this feature. We all know that there is a directory named with your package name under the /data/data directory after your app installed by user. If your app is uninstalled by user, the root directory of your app(/data/data/com.example.yourappname) will be removed by system. The remove action happen immediately when user click "uninstall", and the directory will be removed by framework package manager system.
So, we can monitor the existence of your app data directory(which usually /data/data/com.example.yourappname) to detect if your app uninstalled by user.
In order to monitor this directory, we have to fork a detached process from JNI.
In this new fork process, we can use Linux system api inotify(7) or access(3) to determine the existence of app's data directory.
Here is a workable implementation. But it got the permission problem when try to send an intent to start system browser on high version Android device. I have no idea how to bypass this. However the example above is enough for your question.
Hope it will be helpful!
Android doesn't provide an inbuilt function for tracking the app uninstall.
Notification can be used as an alternate way to track the app uninstall. For this send notification on the app and track the status of the notification. Count the number of undelivered notification for a particular time period. If status of undelivered notification doesn't change in that particular time period, then consider that the app has been uninstalled from the device.
For example, i have used a cron script which run every 3 days and check the status of last 10 notifications delivered to the device (2 notifications are sent in a day). If all of these 10 notifications have status "undelivered", then the app is considered to be uninstalled from the device.