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.
Related
I'm creating an app, that heavily relies on LocationServices.
For now I'm asking user to turn them on, and everything works fine.
However, when user clicks "No", the whole point of this app goes to hell.
I can spam user to turn location services on from my Service, however I find this solution extremely non-elegant.
Is there a way to turn this setting on programatically? I don't care for additional permissions or so.
I did my research and I only got what I already did - ask user to turn on location services with a dialog etc.
Is there a way to turn this setting on programatically?
Fortunately, no, for obvious privacy and security reasons, except perhaps on rooted devices.
However, when user clicks "No", the whole point of this app goes to hell.
Then advise the user once (per run of your UI) that your app cannot function, and the user should uninstall your app.
Bear in mind that many more permissions will have this same sort of user-recovable behavior with Android M.
You simply cant , if that was possible then you can easily gather locations which is for some unethical reasons could be sold ... so for security reasons its not possible at all .
you can always force the user to click yes by making a really useful and helpful application that the user simply want to try and cant click no because it wont function at all ...
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.
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 don't want to do advertisement but sample app for behavior of my application is ESET antivirus.
One requested feature of my application is that for uninstall is needed password. I add my app to device admin list and it is not possible to uninstall it now. But you can Deactive app as admin device. Whan you go to Settings > Location & security > Select device administrators and you try to deactive ESET Security it starts the activity (I guess from DeviceAdminReceiver.onDisableRequested()) which is waiting for password and your mobile is locked. Home button, back button and even SwitchOff button doesn't react=>
How it is possible that Home,Back,SwitchOff and Camera button doesn't react?
EDIT - second question removed
(After I took out battery from my phone - ESET wasn't device admin too)
Thank you for ideas.
Ok, sorry ESET but this feature looks very interesting so I took a look at decompiled sources :)
The basic workflow is the following:
com.eset.ems.antitheft.receiver.AdminReceiver subclass of DeviceAdminReceiver is registered for broadcast actions DEVICE_ADMIN_ENABLED and DEVICE_ADMIN_DISABLED
When device admin is disabled com.eset.ems.antitheft.receiver.AdminReceiver.onDisabled() is called
com.eset.ems.antitheft.LockActivity is started from the AdminReceiver.onDisabled()
LockActivity shows com.eset.ems.antitheft.LockingDialog where the most blocking magic happens
As for the Home and other button block antivirus do the following trick - it uses ActivityManagerNative from Android internals. To keep LockActivity at the top of all other activities it starts a thread which contsantly calls ActivityManagerNative.moveTaskToFront() with LockActivity task ID. Prior to API level 10 reflection is used to access hidden moveTaskToFront() from ActivityManager class and after API 10 it just uses ActivityManagerNative code from Android codebase to access it.
Also both LockActivity and LockingDialog call ActivityManagerNative.closeSystemDialogs() method many times. Probably this is done in order to cancel system dialog which arises after power button long press.
As for the stopping execution of DeviceAdminReceiver.onDisableRequested actually I didn't notice anything special about it in the code. It only starts the activity after device admin is disabled and that's all. And on my phone device admin was disabled after I took the battery out.
Is it possible to track on Android from where somebody has started an application (i.e. from the drawer, from recent apps menu, or from desktop shortcuts, etc.)?
Sorry, but this isn't possible.
Even if it was, consider how easily such functionality could be abused by malicious software. You can listen to intents directed at you, and those that are broadcast, but application launching should not be a broadcast event.
What you may be able to do is replace the launcher. If the user agrees to it.
You might also be able to hack a work-around by reading the logcat logs. For instance, give your application the android.permission.READ_LOGS permission and parse the logs to determine the application that launched it. This is just an idea, however... it sounds like something you wouldn't want to rely on.
If you built your own home screen it could give you some of that information.
But on a stock device with any available home screens no probably not.