SOTI is a remote device administration system that offers a number of features.
One of them is the ability to execute scripts on Android phones remotely, provided that the SOTI client software is pre-installed and configured. The client program does not require a rooted device but it does act as a device administration.
One of the commands allowed in the SOTI scripting language is
wipeapplication com.example.notepad
This results in all of the app's (in this case a notepad) data being deleted, but not the actual APK file. So it gives you a clean slate for whatever application you specify. I understand that this could be done with root through the following:
rm -rf /data/data/com.example.notepad
But somehow SOTI is doing it without root. Just as an Android device administrator. Now the Android DeviceManagerPolicy class does have a wipe method, but its not application specific. Presumably, if there's a way to wipe the whole device at a certain permission level, there ought to be a way to wipe one app's data. But I haven't been able to find out which command is being used? How does SOTI do this?
To uninstall an Android application with bundle ID com.example.notepad , use the following script in Soti Mobicontrol:
uninstall com.example.notepad
Related
I need to run a security test on one of our Android mobile applications.
It must not run if the device is rooted.
It should run as expected on non-rooted devices.
I have tested part 1 without issue and found it to work as expected.
However, I cannot seem to create an emulator using the AVD Manager that will not start with root access.
-Is there a command line method to reduce the emulator instance to non-rooted at startup?
-Failing that, is there a method to send an adb shell command (or other command line call) to reduce the permissions to the installed application?
Thanks!
Edit for #Fred.
I have opened the shell and changed it to the user id (uid) of the application under test. Note that in the image you can see the command, "adb shell su u0_a53" and then the next prompt includes the user, "u0_a53#generic_x86_64" as the returned shell and has the "$" indicating non-root access. However, when opening the application under test on the emulator, the application detects the device is rooted. What am I missing?
See attached image - click here
Yes, there is a way using SU to change super user to non root, see answer in this so question for directions:
https://android.stackexchange.com/questions/60599/how-to-get-non-root-access-on-emulators
As it turns out, my question was fundamentally flawed. The environment i'm trying to achieve could not be created with an emulator as part of the security test checks to see if the phone is in 'release' mode, in addition to looking for the presence of 'su'. After conferring with several other teams, I have decided to obtain a physical phone for testing this security restriction.
How can I send Intent to shutdown the phone if I have a rooted phone?
I put the app in system/app but this was not good enough. What more do I have to do?
It says in docs about public static final String ACTION_SHUTDOWN:
This is a protected intent that can only be sent by the system.
What does it mean only sent by the system? If I get my app to get correct UID,
can I do it then? Or can it absolutely never be done even on a rooted phone?
The Android source in GrepCode suggests that before Android 4.0 this was a signature-only permission, but is now signature or system. This means that you either have to be signed with the key that was used to sign the platform (usually OEM apps only) or be in the /system/app folder. In more recent versions of Android this folder is /system/priv-app to allow vendors to distribute built-in applications with different levels of trust.
You can run an adb shell command as root to shutdown the device.
I've been looking for an answer or the past 3 days, and haven't yet found one that works. I'm trying to write an Android app that can be controlled from ADB with custom commands. Is there anyway I can send strings back an forth between an app and an ADB shell?
Thanks in advance, and sorry for my noob qustion.
Sure, there are several ways to do this.
You could use a unix domain socket, and open it from both the android app and from a command line executable you would build by abusing the ndk, push to a version-dependent location on the device (/data/local, /sqlite_stmt_journals, etc) and run. Edit: in more recent android versions there may not be such writable/executable directories. You may have to have the app itself write the executable out to its private directory and set global read and execute permissions on it. Further Edit: adb can forward unix sockets, too.
Same thing with an internet socket, only now you have the option of setting up an adb port forward (provided the android app is the 'server' end) so as to communicate from a process running on your development machine directly with the android app, without passing data through the adb shell. Unless declaring internet permission is objectionable (it should be less of a concern than letting your PC-side app "drive" adb) this is probably the method that would stick closest to "official" capabilities and have the least android version dependence. It also can be trivially adapted to communicating over wifi.
You could use a pair of fifos and write and read them with shell commands (for portability, create them in the app's private storage but make them world readable/writeable)
you may be able to play some games with a pty
you could I suppose use files as mailboxes
you can use the 'am' command to send Intents (useful at least to start up the android app, if a bit inefficient for the communication)
We are developing an android application which is to be installed on the ~500 devices in the premises.How can I do it centrally at one go via wifi network.
Thrice every quarter, the following is required
The application (upgradeable version) needs to be installed.
Uninstalled (older version) frequently.
I know on device we can set "allow unknown sources" by default. But is it possible to push/install the application (like the ICS push on the Ginger Bread Mobile Phone recently)
I have gone through this post but no precise answer.
For the initial install, you can't. You have no choice but to manually install the app by one means or another (e.g., download it via a link from your intranet).
For updates, the app can check for an available update, download it, and then initiate an install when the user is ready. You cannot forcibly upgrade the app though -- the user will have to be involved.
You also cannot "installed (upgradable version)-uninstalled (older version)" except by hand -- once the app is uninstalled, it has no way to trigger installation of some other app. Also, by uninstalling, you lose all your data, which is generally frowned upon. Upgrading in place is the more typical approach.
Unless you have a custom version of Android on a device you cannot send an APK to the device and have it install automatically without using the Android Market.
However you can deploy applications to an individual device without user interaction using ADB . Using the following command:
adb install /Path/ToFile/ApkFile.apk
Additionally you can put the apk on the phone and then install it using the package manager.
It seems almost every android device comes without root permission, so some people provide a new ROM to root it. How do they achieve it? (Do they change anything in init process, or do they change some apps' access attributes on the storage, such as launcher or toolkit, or some process's uid/gid?)
I have a non-root mobile and another rooted one. I can't find the difference between them. The launcher are both with a uid/gid exceeding 10000.
In Linux desktop, this is controlled through the login process. But I still don't know the key reason.
It's confusing.
On a rooted Android, you can install apps that require special access (like the hardware)
Because the hardware manufacturers and the developers at Google did not want to let users tweak the hardware, the root user is blocked.
For example you can run softwares like Titanium backup (for making backups of application data), SetCPU (for overclocking your Android) and LES (Linux enhancement suite) if you have a rooted phone. Note that the rooted phone will allow apps to run through root only when asked for. Otherwise all the apps will work as the normal user.
In Linux, you can use the su command to get ALL the root permissions or sudo to get minimal root permissions (controlled su)
You can get the superuser permissions by rooting the phone, installing a terminal (Better Terminal Emulator) and typing "su" into the console. (Click "yes" if Superuser asks for permission)