I've been doing some experimentation with Android in order to lock down a kid's phone. Ideally, I'd like him only to be able to use apps that have been pre-installed on the phone; he spends and inordinate amount of time playing games on the phone. I found out that I can disable the Google Play Store on the phone (once rooted) by issuing the command pm disable com.android.vending.
However, I suspect that this setting will not persist of the kid factory resets the phone (he knows how to as he's done it before when I locked down his phone with a 3rd party app).
I've managed to get AOSP built and running on the phone and installed the necessary Gapps for Google Fi (our carrier) and other bare essentials, but I want my final Android image to default to com.android.vending being disabled by default unless explicitly re-enabled after, say, a factory reset.
Now, my knowledge of Android is somewhat limited, but from what I have found via some of the pm source is that the default enabled/disabled status is specified in the AndroidManifest.xml within the APK package. Since I'm trying to disable a Google app, I likely won't be able to modify this.
So, instead I was attempting to figure out via the pm source how exactly pm goes about marking an app as disabled. Unfortunately, my Java comprehensions is terrible so I wasn't able to ascertain anything about the internal workings of how pm does this.
Is there any way that I can cause com.vending.android to be disabled in my system root by default when building AOSP?
Update 1: It seems that the app disabled status is user-dependent. So, disabling the app for one user does not disable for any others. But, surely, there is a global settings file somewhere that the user configuration inherits from...?
Update 2: So, looks like pm works with an in-memory state that is not saved (at least for system apps) even upon a reboot.
You should just buy an old phone for your kid. Factory reset will erase everything you have install, including security programs.
Related
Note: This was originally posted on Android Enthusiasts Stack Exchange but is now moved here because it was found to be off-topic there
Kaspersky Safe Kids, a parental control app, has a feature where it would pop up every time it detects an event that the child was not meant to do (open an app, open anything related to its settings, search something banned on Google and Youtube -- interestingly enough, it doesn't work on other Chromium-based browsers). I've been trying to figure out how it can detect events for my own app, but the usual culprits like the permissions GET_TASKS and READ_LOGS are depreciated (I'm trying to target, and Kaspersky works on, Android 10+). For the actual overlay, I thought it used SYSTEM_ALERT_WINDOW, but in my own experiments in an emulator, when I revoked that permission, it was still able to pop up. So, how does it work, and what permissions do they (and I'm guessing other similar control and productivity apps) work?
The app is Device Admin, so that may play a role, but looking at the permissions a Device Admin has, none of them look like the permissions Kaspersky has.
EDIT: In the comments, Mike M. noted that the app uses Accessibility Services (don't know how I missed that), which makes sense as Accessibility allows you to do quite a lot, including showing your own UI. Coincidentally, a review on the app itself states that the process ends at random times (not sure which process though), probably because it was not whitelisted. I then took a look at its permissions and this one stood out: android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. This permission allows it to be whitelisted, so that power saving modes don't kill the background processes. For the accessibility itself, android.permission.BIND_ACCESSIBILITY_SERVICE is the permission used to grant it (for the record, you must use adb shell appops set com.kaspersky.safekids android.permission.BIND_ACCESSIBILITY_SERVICE [allow|ignore|deny], not adb shell pm [grant|revoke] com.kaspersky.safekids android.permission.BIND_ACCESSIBILITY_SERVICE (though the android may have to be replaced with Manifest) as BIND_ACCESSIBILITY_SERVICE is a signature permission. For completeness, for Admin, it's android.permission.BIND_DEVICE_ADMIN.
I was able to narrow down the exact permission used -- using ADB OTG (I didn't have a computer near me, so I used my spare Pixel) I did appops set com.kaspersky.safekids BIND_ACCESSIBILITY_SERVICE ignore (I belive deny would work too). Restarted it, and no more pop up. Changed the ignore to allow, then rebooted, and it worked again.
I need to update multiple applications installed on many Android devices.
Is there anyway to put theirs updated apks on USB flash drive, write some script that updates them and run this script manually after I plug it to the device?
I guess the most basic question would be why? Is this something you are purposely keeping off the app store? If it is not TOS breaking just pay the 25$ for a dev account and you can even just keep it in a beta/alpha status so only people you allow to can download it.
Beyond that Android phones can install APK's from third party sources, host the APK somewhere or get it to the user in some fashion and they can download from the phone and install.
Really the app store is your best bet.
It really depends on your use case and control of the devices that you are updating. Using an OTA update tool is always the fastest option for getting upgrades out. You can use BETA distribution, or TestFairy, or even hockey app, however, if you are not choosing to use these items then you will need to do a little extra leg work. Don't worry I won't patronize you with "why are you doing this", you asked a question so I'll do my best to answer it.
1) Register a service or app who's whole goal is to update others. Maybe you call it updateService.
2) Register a Broadcast Receiver for the updateService that listens for USB connected
3) Read the contents of the USB stick to know what needs to be updated. Possibly a folder system where you check "if folder exists, then update" or you can keep a local sql db of update service ownership that keeps track of last updates or current versions.
4) Once you see what needs installed have your service run ADB Install commands. However, if you have new permissions added then user interaction would be required unless you have root access or system level privelages on your update service.
Here is a package installer thread that will give you some ideas of how to silently update. Install apps silently, with granted INSTALL_PACKAGES permission
So the short answer is, yes you can do it, but the longer answer is revolving around the type of control you have, and if you have root or system level access and how much leg work is it worth to you. If you are ok with User Interactions on install then you won't have to worry as much, but I'm guessing you want silent installations.
Hope that helps.
Does anyone know what is the behavior in production of a device-owner App, distributed thru Google Play, when updates occur?
As we know, installing a device-owner App involves some motivation and is not easy: reset to factory default then NFC-provision the device with a second device etc… So even if we consider this step done, would any further update involve so much pain, each time?
This question occurs because on my development device, I cannot re-launch the device-owner App with changes if it was previously installed… unless I reset the device to factory settings!
Thanks for reading…
Once your Device Owner app is set, a new file is created under /data/system/device_owner.xml that references the Device/Profile owner apps.
The Android system is then reading this file to check which application is considered as Device Owner or Profile Owner App.
This file contains refers to the applications by using their package name. Updating these apps won't infer on this file since the package name stays the same.
When you're updating your app, just make sure you're always using the same certificate as the one you previously used when first setting you device owner for the first time (which is a standard rule of security for every application update in Android anyway).
Permissions can also be updated the same way, without the need to reprovision it through NFC, nor dpm tool.
This question already has answers here:
Is it possible to detect Android app uninstall?
(8 answers)
Perform a task on uninstall in android [duplicate]
(4 answers)
Closed 7 years ago.
I though it was not possible but I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called.
I would like to replicate this behavior in my App.
I tried with an Activity listening to "android.intent.action.DELETE" Intent, as suggested here:
How to know my app is uninstalled from the device...?
But as I'm about to uninstall my app, the chooser pops up asking to pick my application or the package uninstaller. How can I avoid this?
Is there a different way to intercept your application UNINSTALL event? (before answering that it is not possible, please try to uninstall NQ Mobile Security and see what happens. On my Android 2.3.4 it shows a nice screen saying that is not safe to go without a security app).
I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called
They must be exploiting some security flaw in Android. I will research it and see if I can get it fixed. Apps are not supposed to get control at uninstall time.
Thanks for pointing this out!
Is there a different way to intercept your application UNINSTALL event?
I sure hope not.
Opera Max is an app that does something similar - after being uninstalled opens a webpage.
How do they do this?
By using libevent, from native code, they watch /data/data/com.opera.max directory to be removed and then post good old action.VIEW broadcast when it happens.
Install their app, run it, and on rooted device from adb shell remove /data/data/com.opera.max directory
UPDATE: I created a sample app that shows how it works. BTW it doesn't work with recent (KitKat+ I think) Android versions: https://github.com/pelotasplus/ActionAfterUninstall
I'm pretty sure that they are monitoring the LogCat to intercept when the Activity Manager calls the PackageUninstaller. I think they kill the task and start their own Activity.
It's pretty clever but it's definitely exploiting a security hole in Android.
They are likely asking for a very critical permission that the user is granting them unknowingly. Look at the "Permissions" tab for this app (as of 6/15/2012): https://play.google.com/store/apps/details?id=com.nqmobile.antivirus20&hl=en.
The list of permissions this app gets is downright chilling. Among other things:
SYSTEM TOOLS RETRIEVE RUNNING APPS Allows the app to retrieve
information about currently and recently running tasks. Malicious apps
may discover private information about other apps.
CHANGE/INTERCEPT NETWORK SETTINGS AND TRAFFIC Allows the app to change network settings
and to intercept and inspect all network traffic, for example to
change the proxy and port of any APN. Malicious apps may monitor,
redirect, or modify network packets without your knowledge.
PREVENT TABLET FROM SLEEPING PREVENT PHONE FROM SLEEPING Allows the app to
prevent the tablet from going to sleep. Allows the app to prevent the
phone from going to sleep.
CHANGE YOUR UI SETTINGS Allows the app to
change the current configuration, such as the locale or overall font
size.
MODIFY GLOBAL SYSTEM SETTINGS Allows the app to modify the
system's settings data. Malicious apps may corrupt your system's
configuration.
DISPLAY SYSTEM-LEVEL ALERTS Allows the app to show
system alert windows. Malicious apps may take over the entire screen.
MOUNT AND UNMOUNT FILESYSTEMS Allows the app to mount and unmount
filesystems for removable storage.
CHANGE NETWORK CONNECTIVITY Allows
the app to change the state of network connectivity.
CHANGE WI-FI STATE Allows the app to connect to and disconnect from Wi-Fi access
points, and to make changes to configured Wi-Fi networks.
-- Update --
I also found that the Android Package Manager pretty much just deletes a package if it is asked to do so. The only check it performs prior to doing so is whether the package being deleted is currently registered as having an active device admin:
try {
if (dpm != null && dpm.packageHasActiveAdmins(packageName)) {
Slog.w(TAG, "Not removing package " + packageName + ": has active device admin");
return PackageManager.DELETE_FAILED_DEVICE_POLICY_MANAGER;
}
} catch (RemoteException e) {
}
See line 6900 in PackageManagerService in the AOSP source here.
For this, the application must be explicitly registered as a device admin by the user. See notes on device administration here: http://developer.android.com/training/enterprise/device-management-policy.html.
As per https://stackoverflow.com/a/26829978/1317564, here is some example code that does it: https://github.com/zzljob/android-uninstall-feedback/blob/master/library/jni/feedback-uninstall.c. This won't actually stop the uninstall from taking place, but does provide a way to catch it and take some action. I'm honestly surprised that this works in Android and the team may have plugged the gap in recent releases.
I always wonder how Android's BackupManager will act when the same BackupManager enabled App is installed on multiple devices (e.g. Smartphone and Tablet) linked to the same Google Account. It seems that I am not the only one, but I couldn't find any specification about this.
What's your experience with this scenario? Are there any official resources that describe that case?
This mechanism doesn't have any user-facing documentation, nor a lot of documentation for app developers, since it's supposed to automatically do the right thing, but the code is available. All the information below comes from inspecting the source code and from the documented options of the bmgr tool. This answer is adapted to be more developer-oriented, from a user-friendly answer I originally wrote on the Android Stack Exchange.
Let's talk about sets, baby
Android's backup service has a concept called a set: the set of all data backed-up from one device on one transport. Each set is identified by a unique string, such as the IMEI on the device. When an app (or the list of installed apps) is backed up, its backup data go into the set associated with the device it's being backed up from. All the sets are still specific to the user's Google account. If you wipe your device and sell it to someone else, he won't be able to access that device's set unless he can log into your Google account.
Default behaviour
When an app is installed, or a device has its list of apps restored, the backup system first looks in that device's set for backup data for that package. If it doesn't find any (either because it's a completely new device with no backed-up data, or because that package has never been installed on that device), it'll expand the search to other sets. (If there's a choice, it'll use the last set that was used for a full-device restore.)
Thus, when you set up a new device, it'll restore the list of apps from an old device's backup, and restore each app from the old device's backup. If you had an app installed on one device and you install it on another device, the app will be restored with its data from the old device. In either case, the data are now backed up into the new device's set, which means that the backup data from the two devices are separate from now on.
After you factory-reset a device, it'll restore from that device's last backup if there is one, and failing that, from some other device's backup if there is one, but it will start to create its own set from then on.
bmgr: basic use
The bmgr tool is intended for debug and test, and gives you a little control over the backup/restore process. You can use this tool in an adb shell to trigger backups and restores of chosen packages, wipe packages' backed-up data, and even a whole-device restore.
Don't try to use it in an on-device shell except as root: you need the system-level android.permission.BACKUP to do anything interesting with it.
For testing, you can make a package update its backed-up data immediately:
bmgr backup com.shadowburst.showr
bmgr run
(or whatever the package name is). To restore one package from the backed-up data it would choose by default:
bmgr restore com.shadowburst.showr
This only works on already-installed packages: it won't install a package in order to restore the data. Both these commands are just for testing, since normally the device backs-up and restores data whenever it needs to.
More control
Now for the stuff that the backup system won't do on its on. To see what sets of backed-up data are available:
bmgr list sets
and you'll get some output like this:
3ff7800e963f25c5 : manta
3f0e5c90a412cca7 : manta
3dd65924a70e14c8 : TF101
3baa67e9ce029355 : m0
The 64-bit hex number on the left is called a token, and uniquely identifies the set. The thing on the right is a (relatively) friendly name for the device that owns the set. For example, manta is the code name for the Nexus 10; TF101 refers to the original Asus Transformer. You can restore a package's data from a set of your choice, by specifying its token:
bmgr restore 3ff7800e963f25c5 com.shadowburst.showr
You can add more package names to the end of the command to restore several packages at once, or you can specify no package name (just the token) to restore every package with data in that set (that is, it does a full-system restore).
Finally, you can wipe an package's data from the current set:
bmgr wipe com.shadowburst.showr
This will make its next backup operation start from scratch. This might be useful while debugging your backup code.
You can't make a device start writing into a different set, nor can you wipe a whole set in one go.