Posts Tagged ‘Android SDK’

Rooting the Android Emulator – on Android Studio 2.3 (Android 4.4+)

March 6, 2017 Leave a comment

Having struggled to easily find instructions on how to run apps as root on the Android Emulator, I’ve decided to document what worked for me. I’ve tested this on the emulator bundled in Android Studio 2.3 with an emulator running Android 4.4 (Kitkat)and 7.1.1 (Nougat).

NB: Basically, through ADB (the Android debug bridge) you can get root access to the filesystem (only). This means you can access privileged directories, change file/directory permissions, put apps and binaries in certain (many?) locations (not in the system partition, unless you make it writable), and run them via the command line interface. However, this does not mean that you will be able to run apps in the emulator directly as root.

Getting access to the filesystem as root is as easy as running:

adb root

or getting into the emulator and using su , i.e.:

adb -e shell

su root

Notice the # telling you that you are root. (The -e just means to direct the adb connection to the  emulator)

Now this is NOT exactly what I wanted, I wanted more!!

Rooting the Emulator:

Tl;dr: The basic idea is to get the correct su (superuser) binary from the SuperSu project by Chainfire (Jorrit Jongma), put it in the right directory, change the permissions. Install the SuperSu app, turn off SELinux policies and set up a daemon. I won’t claim I understand the whole process (particularly the daemon part), but i’ll document below what worked for me.

I’ll assume we’re using a Windows machine as the host. (Running these on Ubuntu, or some other Linux /Unix flavour should not be too different).

Step 0: Installing the SuperSu app

Ideally this step could come first before everything else, or last, after everything else. If you install it now you, and try to run it, very likely it would indicate that the su binary was not installed. If you try to run it after all the steps below, it should open error free and (without the dialog telling you that the binary is not installed).

Install the Supersu app either from Google Play or sideload it through adb. The links are available at the SuperSu downloads section.

Install the Supersu.apk file through sideloading as follows:

adb -e install supersu.apk

Step 1: Start up the emulator with a writable system partition.

emulator.exe -avd [emulator_name] -writable-system

Step 2: Get the SU binary and put it in the right directory

You can download the Superuser binary from the supersu downloads section. Download the latest ZIP files. (As of writing this is Recovery Flashablev2.79). Unzip the archive. Locate the su binary for the correct architecture of the emulator that you are using. In my case i’m running an emulator with Android x86 (on a Windows device), so i look under the x86 directory of the SuperSu ZIP archive. NB: If you are using Android 5.1 and above (or if you are getting some errors about Position Independent Executables [PIE]), what you need is the su.pie binary, rather than the plain su binary.

We now need to put the binary into the correct location as follows:

Make sure you are running adb as root using. Not sure why you need to remount, but for some reason it enables writing to the system partition, (after having used the -writable-system directive).

adb root

adb remount

adb -e push C:\SuperSU-v2.79\x86\su.pie /system/xbin/su

Remember that if you are using an Android emulator with a version lower than Android 5.1 you likely will have to use the plain su binary (not the su.pie)

adb -e push C:\SuperSU-v2.79\x86\su /system/xbin/su

Not sure why, but some resources suggest that you need to push the binary to /system/bin/ for some Android versions. For good measure you can just do it, just incase.

Now we need to get into the emulator device through adb and change the permissions of the su binary.

adb -e shell

su root

cd /system/xbin/su

chmod 06755 su

For good measure, if you also put the binary in /system/bin/su you can also traverse into that directory and put the permissions of 06755 on the su binary there in. (I can’t remember exactly whether i used 06755, or just 755 as the permissions, but I seem to vaguely remember the former as what I used). Also i noticed that originally the permissions on the su binary in the emulator had rwsr_x_x permissions if i remember correct.

Step 3: Set the install directive on the su binary and set a daemon

I’m not entirely sure what is going on in this step, but it looks like the su binary may have a --install directive to install some more things (maybe??). I just followed [1] (from Android StackExchange).


su --install

Now we set up the daemon, (also taken from the same StackExchange post)

su --daemon&

Notice the ampersand (&) at the end of the line with no space before. This indicates that the daemon (service) should run in the background.

Step 4: Set SELinux to Permissive (i.e. turn off SELinux)

This step essentially turns off SELinux. Logically this step sounds like it should have come earlier, but for some reason it came at the end and still worked.

setenforce 0

In my situation, at this point the emulator seems to have hung/crashed. I just terminated it.

Now you can restart the emulator via the command line, or via Android Studio. It should start up successfully. If you had installed the SuperSu app then you can just run the app and it might prompt you that there is a new version of the binary. Install it via the “Normal” option (if prompted).

At this point everything should be working well, and you can test some other app that requires root permissions to  verify that the su binary is installed correctly and that the SuperSu (Gatekeeper) app fires correctly to “Grant” or “Deny” access to the requesting app.








Android App Developer Guide – My Own Beginner Notes

January 30, 2017 Leave a comment

Various notes (adapted) from the Android SDK Developer Docs (for creating one’s first App):

The at sign (@) is required when you’re referring to any resource object from XML. It is followed by the resource type (id in this case), a slash, then the resource name (edit_message). [Source]

The plus sign (+) before the resource type is needed only when you’re defining a resource ID for the first time. When you compile the app, the SDK tools use the ID name to create a new resource ID in your project’s file that refers to the EditText element. With the resource ID declared once this way, other references to the ID do not need the plus sign. Using the plus sign is necessary only when specifying a new resource ID and not needed for concrete resources such as strings or layouts. See the sidebox for more information about resource objects. [Source]

The default weight for all Views is 0, so if you specify any weight value greater than 0 to only one View, then that view fills whatever space remains after all Views are given the space they require. [Source]

It’s a good practice to define keys for Intent “extras” using your app’s package name as a prefix. This ensures the keys are unique, in case your app interacts with other apps [Source]

The XML layout generated by previous versions of Android Studio might not include the android:id attribute. The call findViewById() will fail if the layout does not have the android:id attribute. If this is the case, open the relevant .xml file in the /res/layout directory (in this case activity_display_message ) and add the attribute android:id="@+id/activity_display_message" to the layout element. [Source]

Android categorizes device screens using two general properties: size and density. [Source]

  • There are 4 generalized sizes: small, normal, large, xlarge
  • And 4 generalized densities: low (ldpi), medium (mdpi), high (hdpi), extra high (xhdpi)
  • Also be aware that the screens orientation (landscape or portrait) is considered a variation of screen size, so many apps should revise the layout to optimize the user experience in each orientation.

Information about the relative number of devices that share a certain characteristic, such as Android version or screen size [Source]

Using the appcompat Toolbar makes it easy to set up an app bar that works on the widest range of devices, and also gives you room to customize your app bar later on as your app develops [Source]

You should always externalize application resources such as images and strings from your code, so that you can maintain them independently. You should also provide alternative resources for specific device configurations, by grouping them in specially-named resource directories [Source]