I was researching background location in Expo when I found that apps need permission from Google to use this on Android.
If the Android phones are running developer mode with sideloaded APK files, do they still need to have permission to use background location? If this is the case, is there any way to bypass it on a per-phone basis?
Thank you.
Allowing some apps to bypass location restriction is a security breach.
All apps must comply with the rules.
It is also our interest, as developers, to develop in real environment.
What you can do:
Create a script that installs your app and grant all location permissions using adb (replace com.name.app with your app package):
// Linux
./gradlew installDebug
// Windows
gradlew installDebug
adb shell pm grant com.name.app android.permission.ACCESS_COARSE_LOCATION
adb shell pm grant com.name.app android.permission.ACCESS_FINE_LOCATION
adb shell pm grant com.name.app android.permission.ACCESS_BACKGROUND_LOCATION
Edit
Just noticed that you work on react native, which I'm not familiar with
If you don't have gradlew commands, you can use adb install APK_PATH with the path of the apk, that is generated by react native.
Even better if you have a react native cli command to build and install app
Related
I tried updating an APK using this code:
Process process;
process = Runtime.getRuntime().exec(new String[] {"su", "-c", "pm install -r -d"+MyApk.apk});
but it does not work.
This works well when I use it with adb like:
adb shell su -c pm install -r -d /system/app/Community-debug.apk
It also works fine if it has to ask for user permission in order to install like using the intent method.
Your application would need to run as System user to access this level of commands. It cannot be done in any way if your app is distributed using standard channels, e.g. Google Play, installing from SD card, or installing by ADB. None of these would let your app breach the security.
Having said that, there is a way to get it working, but that way is for privileged distribution only. Your app must:
include android:sharedUserId="android.uid.system" in the AndroidManifest
be signed with the certificate which is used to sign the rest of the system
be pre-installed in one of the privileged locations: /system/app, /system/priv-app
Once your app satisfies these requirements, it can execute commands like pm install, even without the su
Needless to say that such options are only available to large bodies like telecom providers who sell their own-branded devices.
Your solution will only work on rooted devices.
In order for it to run on all devices, firstly, you need a cooperation from the device manufacturer to put your app under /system/priv-app. Putting your apk there will give you system privileges enabling you to perform the install.
On top of that, you need to add android.permission.INSTALL_PACKAGES to your manifest file.
Finally, add these lines to your code:
Runtime.getRuntime().exec("chmod 777 " + MyApk.apk);
Process process = Runtime.getRuntime().exec("pm install -r " + MyApk.apk);
While migrating one of my apps to use the Android 6.0 permissions system, I found it very hard to debug permissions using the emulator.
Findings:
Disabling a permission in the app info screen doesn't re-show the grant permission dialog when using the requestPermissions() method.
Reinstalling the app seems to be the only way to make the app show the grant permission dialog again.
What is the proper method to debug permission using the Android emulator?
It’s actually very easy to debug Android 6.0 permissions. You can reset the permissions to the "install state" for the current foreground app all apps using the following ADB shell command:
adb shell pm reset-permissions
Note: Currently you can't reset the runtime permissions for a specific package, the package manger (pm) tool help section states:
revert all runtime permissions to their default state.
You can easily execute the reset-permissions command using the terminal interface in Android Studio. Note that ADB commands only works if the ADB directory is added to the PATH system environment variable (see: add ADB to path variable).
You can also reset/revoke a specific permissions using:
adb shell pm revoke com.your.package android.permission.WRITE_EXTERNAL_STORAGE
A downside of this command is that it will restart your app, but this doesn't reset the runtime permissions for all apps. To grant a permission replace revoke with grant.
I tried updating an APK using this code:
Process process;
process = Runtime.getRuntime().exec(new String[] {"su", "-c", "pm install -r -d"+MyApk.apk});
but it does not work.
This works well when I use it with adb like:
adb shell su -c pm install -r -d /system/app/Community-debug.apk
It also works fine if it has to ask for user permission in order to install like using the intent method.
Your application would need to run as System user to access this level of commands. It cannot be done in any way if your app is distributed using standard channels, e.g. Google Play, installing from SD card, or installing by ADB. None of these would let your app breach the security.
Having said that, there is a way to get it working, but that way is for privileged distribution only. Your app must:
include android:sharedUserId="android.uid.system" in the AndroidManifest
be signed with the certificate which is used to sign the rest of the system
be pre-installed in one of the privileged locations: /system/app, /system/priv-app
Once your app satisfies these requirements, it can execute commands like pm install, even without the su
Needless to say that such options are only available to large bodies like telecom providers who sell their own-branded devices.
Your solution will only work on rooted devices.
In order for it to run on all devices, firstly, you need a cooperation from the device manufacturer to put your app under /system/priv-app. Putting your apk there will give you system privileges enabling you to perform the install.
On top of that, you need to add android.permission.INSTALL_PACKAGES to your manifest file.
Finally, add these lines to your code:
Runtime.getRuntime().exec("chmod 777 " + MyApk.apk);
Process process = Runtime.getRuntime().exec("pm install -r " + MyApk.apk);
I'm running on a device with a custom Android platform for which I have the platform.keystore certificate. I was able to build an application, sign it with the platform key, and install it on my device. However, now that the package has been installed, I can't seem to uninstall it from the command line.
Since the device is running a production build of the OS, I can't run adb root from the command line to gain permissions. Also, I'm unable to run su from adb shell since I don't have permissions, so I can't go into /data/data and force remove the package.
I can think of a couple ways of uninstalling the package NOT from the command line:
Go into Settings->Apps and click Uninstall
Create another platform-signed app that uses reflection to access the uninstall API from PackageManager to uninstall it. Along these same lines, I could have the app send an Intent to PackageManager to prompt the user to uninstall the package.
That's great, but I'd really like to be able to uninstall the package from the command line. It seems like there should be parity here. Is there a way to uninstall a platform-signed package from the command line considering I have access to the signing certificate?
Do you know the app's package? If so, try
adb uninstall *com.name.of.package*
(as documented, for instance, at this site ).
I'm attempting to install an apk programmatically, but I'm not having much luck. I'm setting up an automated test framework targeting physical devices, and I want to have the test devices retrieve the latest apk from the build server before running tests. While I am aware that there is no general way to actually install an apk without the user's consent, I'm curious if there might be some approach available in the case where a developer owns both the apk and device.
Approaches I've tried in the past (the apk has been downloaded to pathName/apkFilename):
String command = "adb install " + pathName + apkFilename;
Runtime.getRuntime().exec(command);
And:
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setDataAndType(Uri.fromFile(new File(pathName + apkFilename)), "application/vnd.android.package-archive");
getActivity().startActivity(intent);
While I haven't been able to get the first approach to work, the second attempt creates a system dialog asking the user to confirm the installation (so almost there, but not quite). Since it is a System dialog, I, unfortunately, cannot use Robotium to confirm.
A lot of people are trying to solve similar problems. I believe it may not be possible to install an APK without confirmation, at least not easily:
Silent installation on Android devices
I've accepted for a while now that it's impossible to silently install an application on Android
Install apps silently, with granted INSTALL_PACKAGES permission
You cannot silently install app, its not supported by Android for obvious reasons. Application installation requires user intervention to continue.
Workarounds?
You need the app to have the android.permission.INSTALL_PACKAGES permission.
There are some hints on those threads about how to do this if you have certain priveleges, though it might be hard to get your app to run that way. You might have to install to a special directory, and/or you might have to run as a special user (which might be hard to do).
One possible way to run the app with elevated permissions: How can I get root permissions through the Android SDK?
On this thread, they mention you might have to "root" your phone to enable that permission:
http://www.anddev.org/androidpermissioninstall_packages_not_granted-t5858.html
I wouldn't be surprised if this voids the warranty though. You mentioned in the comments on your post that you don't have "control over the device", so that might kill this option too.
There is some mention on this thread of exploits that some apps use, but I don't think they're supported. If they still work, they might stop working at some point.
I'm trying to do the same thing, in order to push updates to devices we control. In our case they're already rooted, and the application has been granted superuser, so I think just copying the .apk over the top of the existing file would probably work, but this seems very hacky.
What seems like a better approach (if it works) is to use the pm Package Manager application:
# /system/bin/pm
usage: pm [list|path|install|uninstall]
pm list packages [-f]
pm list permission-groups
pm list permissions [-g] [-f] [-d] [-u] [GROUP]
pm list instrumentation [-f] [TARGET-PACKAGE]
pm list features
pm path PACKAGE
pm install [-l] [-r] [-t] [-i INSTALLER_PACKAGE_NAME] [-s] [-f] PATH
pm uninstall [-k] PACKAGE
pm enable PACKAGE_OR_COMPONENT
pm disable PACKAGE_OR_COMPONENT
pm setInstallLocation [0/auto] [1/internal] [2/external]
The list packages command prints all packages. Options:
-f: see their associated file.
The list permission-groups command prints all known
permission groups.
The list permissions command prints all known
permissions, optionally only those in GROUP. Options:
-g: organize by group.
-f: print all information.
-s: short summary.
-d: only list dangerous permissions.
-u: list only the permissions users will see.
The list instrumentation command prints all instrumentations,
or only those that target a specified package. Options:
-f: see their associated file.
The list features command prints all features of the system.
The path command prints the path to the .apk of a package.
The install command installs a package to the system. Options:
-l: install the package with FORWARD_LOCK.
-r: reinstall an exisiting app, keeping its data.
-t: allow test .apks to be installed.
-i: specify the installer package name.
-s: install package on sdcard.
-f: install package on internal flash.
The uninstall command removes a package from the system. Options:
-k: keep the data and cache directories around.
after the package removal.
The enable and disable commands change the enabled state of
a given package or component (written as "package/class").
The getInstallLocation command gets the current install location
0 [auto]: Let system decide the best location
1 [internal]: Install on internal device storage
2 [external]: Install on external media
The setInstallLocation command changes the default install location
0 [auto]: Let system decide the best location
1 [internal]: Install on internal device storage
2 [external]: Install on external media