I'm trying to write an Android service, which starts on boot and works in the background periodically. I have defined the BroadcastReceiver of mine, added the right permissions and all the necessary stuff in manifest.
When I install the APK on my phone and reboot, nothing happens, the program is there in the installed apps section, but not running.
I've seen a user comment stating that "standalone" services are disabled (for security reasons?) since Android 3.1 but I couldn't verify this information anywhere.
Anyone could give me a clear view about this? Without that, I don't know how to proceed: debug or change plans.
Thank you in advance!
Just after the first the first installation of a package, the application is in a "stopped state" preventing it to execute any code for security reasons.
The app loses this particular "stopped state" as soon as the user launch the app explicitly for the first time.
Related
After 3.1 , Android introduced a security feature, where the application's code can't be run unless the user opens the application. Check the link for more info http://commonsware.com/blog/2011/07/13/boot-completed-regression-confirmed.html
I would like to know if anyone has found any hack or work around for this problem, where i can listen to a system broadcasts like boot, connectivity changed and run a service without opening the installed application.
This is not what the posts said. You can still register broadcast listeners, or alarms. You just need the user to actually start your application once. And, if the user forcefully stops your application, they'll need to start it manually again.
Why would you want a way around this behavior? It seems to make a lot of sense.
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.
Why the same question again
This question has been asked around 100 times on SO. I am asking it again because all the answers say this is not possible but at least one of the app in Market is doing it NQ Mobile Security. I started a bounty of 100 points on the similar question but it did not get enough attention. If community does not accept I will remove the question.
What is the App doing
The app shows an activity when user tries to uninstall it
and does some processing before it is uninstalled
What is my Question
How to start an Activity or an IntentService before an application in uninstalled by the user who has earlier installed the app on her device?
As #CommonsWare said The techniques used by NQ Mobile Security have been reported to the Android Security group, and they are working on a fix to stop this behavior from occurring. and have raised a feature request with Google hopefully they may listen to it.
http://code.google.com/p/android/issues/detail?can=2&q=33315&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&id=33315
I think that you can track logcat, where all activities, events, intents are registered and and find when an Intent is sent to uninstall this app.
Then you could possibly perform an action, i.e. launch an Activity, but I am not sure for this step.
Hope this helps!
I don't know how it happen in NQ Mobile Security application,
But in general case I found it not possible (Or may be possible but I couldn't find the way),
Because,
When you register BroadcastReceiver for android.intent.action.PACKAGE_REMOVED in your own app and when the app is uninstalled, the registered BroadcastReceiver has been uninstalled before the app gets uninstalled,so its own uninstallation event won't be received by that BroadcastReceiver.
I know this is old but I want to provide this answer.
Listening on your own uninstall is pretty easy. You just need to use a binary which you execute and runs in background(with nohup command).
This binary can either listen on PACKAGE_REMOVED broadcast or you can regulary check if the file still exists in /data/app/ (these files are world readable, directory listing is disabled, but u know your own package name :) )
I dunno if the second solution can be done without draining battery.
Okay, I'm pretty sure that this is not possible but a client had asked me to do so in one of our Android application we developed for her.
What she had wanted is that if our application is running, and user navigate to:
Settings > Manage Application > [Our Application]
, the button for "Force Stop" is disabled.
Is this possible? If it is possible, could someone point me out which way I should walk, or if it is not possible, how, using a valid argument based on facts, should I break the news to her.
Update:
She just sent me a screenshot that, in her opinion, validates her request that there's an Android application that disables "Force Stop" button. How am I supposed to explain this to her?
How to disable the "Force Stop" button
Short answer: Use the Device Administration API.
How to explain this to my client?
Show this to your client. It is a nice slideshow providing an easy-to-understand overview of the Device Administration API and its uses.
How do I demonstrate that it works?
Yes, back to your job. Use the API link provided above and the Api Demos included in Google's sample
collection to figure out how to integrate this into your app.
Build the demo and run it on your device.
Choose API Demos->App->Device Admin->General->Enable admin.
Choose Activate once the Device Administration API prompts you with its enabling screen.
Exit the app and attempt to manage the app via your device's settings menu (specifics for this step varies by device).
When viewing the Api Demo's "app info" screen, you should see both Force Stop and Uninstall are disabled.
How do I do this in my own app?
Review DeviceAdminSample.java in the Api Demos app for inspiration. You will need the following:
The following code is what brings up the activation screen:
// Launch the activity to have the user enable our admin.
Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
mActivity.getString(R.string.add_admin_extra_app_text));
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
However, there are a few other pieces you will need to get this to work:
A broadcast receiver that derives from DeviceAdminReceiver.
Entries in your manifest file that refer to the above broadcast receiver.
Permissions in your manifest for using the Device Administrator API.
An xml file stating what policies your app can access.
All of this can be found in the above links. Good luck with your client!
This is not remotely possible, for great reason.
You should tell her that making this possible would be a huge security disaster. Imagine what would happen if you could create apps which just ate at your processor time by holding a wake lock, and you couldn't kill them. This would be horrible.
In general, if you're wondering if you can modify the "extra-app" behavior of the device, the answer is usually *no*. You should take the viewpoint that nothing on the device is yours to control besides your app and (to a limited extent) the resources to which you're granted access.
No other app has this kind of control, so it's not reasonable to expect that your client's would either. However, the fact that she's asking for this control usually implies something else: that they are worried the user will stop the app and then something bad will happen (the locations will stop being synced, data will stop being sent out to the net, etc...). This would imply that you should look into improving the resilience of the app to different situations. Remember, your app can even be killed off at any time by Android (for example, in the case of low memory).
I think the device screen shot has confused us. Even I can show my application that is installed on the device and the "Force Stop" button is disabled. Where as I have not done any thing specific to that.
The reason of the "Force Stop" button being disabled is, that particular application is NOT running currently. Hence there is not meaning in having the button enabled.
#Rhama you can ask your client to start the application once, press the home button of the device, and goto the settings and see. Surely the "Force Stop" button will be enabled this time.
Regards,
Rajan
From ICS, disabling Force stop is possible. If your app has an active device admin then the framework will not allow user to kill the process
Hey I think it is quite possible to disable the "Force Stop" button...check Kaspersky
Parental Control from the market it is doing the same.
Its service is running in the background then also the force stop button is disabled.
The application service is running in background
you can disable the forcestop when the app has admin rights. but soon as those admin rights are revoked then it is back to normal. however in android 4, an application called applock (domobile) was able to prevent that by asking a password when you tried to change admin rights. It could only be done by installing an extra program that applock asked you to. And I guess this might even be seen as a security flaw, infact it no longer works in Android 5.
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.