Posts Tagged ‘Apps’

Android: Installing an Android App (APK) as a System App on the Android Emulator (v26) [Android 5.1+]

April 17, 2017 Leave a comment

I wanted to install a couple of APKs on the /system partition so that if I clear out the apps installed in the user partition, or I format/delete the user partition, i don’t lose my stuff.

NB: Installing to the /system partition also seems to have some extra benefits in terms of permissions, but I have not read into the details of what exactly happens. Also uninstalling via the GUI is not available (as far as i can see) once the app is installed on the /system partition

So the basic idea is that we want to get the given APK onto the /system partition and according to most tutorials and explanations i’ve found online it seems to be as easy as just copying the file onto the system partition and rebooting the device. But there are a few caveats that one needs to know. I’ll go through these below while also going through the steps that I used to eventually get my APK’s installed to the /system partition.

Common Steps across all methods:

You need to have the /system partition writable, this is done by first starting up the emulator with the -writable-system directive

emulator -avd -writable-system

The next step is to remount the AVD disks with the adb remount directive (I haven’t looked into what exactly happens here, but it seems to be needed, and works)

adb -e remount

After this, I noticed that there are 2 main methods, either copying the APK directly to the system partition, or installing the APK first to the user partition then “moving” it to the system partition.

The first method is useful for small APK files (i don’t have a specific definition of precisely what “small” means, but read on and you’ll get the idea); while the 2nd method is more appropriate for larger APKs. In general I noticed that larger APK files have other files in them and in the installation process the original APK gets split into a “base.apk” file, library dependencies (into a directory) and a couple of other “split files” derived from the APK. The best way to discover if this will happen to your APK is by using Method 2 (i.e. installing to the user partition, then “moving” the files to the system partition). The libraries and split files have an effect on the way things are installed on the system partition.

Method 1: Directly copying into the /system partition

The basic idea here is to just copy the given APK file either from your computer disk directly to the /system partition, or to copy it first to the SD Card (if available), or from some other writable location on your Android device (e.g. /usr/data/temp).

My suggestion is to create a folder in the /system/app/ directory with the package name of the APK. (it seems it is not entirely necessary, but for the sake of keeping the /system/app directory as clean as possible, i suggest this.)

This is done by going into the /system/app/ directory and using the mkdir command:

adb -e shell

cd /system/app


The next step is to copy the APK from it’s original location into the /system/app directory. This can be done as follows:

If the APK is on your computer disk in some location:

adb -e push <APK_FILE_PATH> /system/app/<PACKAGE_NAME_DIR>/<APK_FILE_NAME>


adb -e push C:\Users\user1\Desktop\myApp.apk /system/app/com.myPackage.package_name/myApp.apk

Since the directory is created as root it will likely have permissions set to 777 i.e. rwxrwxrwx . For security reasons it’s better to change these to something lower. I’m not exactly sure because some resources suggest 644 (i.e. r-xr–r–), while I think 755 is what is needed. All the same, change them:

chmod 755 /system/app/<PACKAGE_NAME_DIR>

If it copied successfully, you can reboot the device either with the Emulator Power button on the GUI, or using the adb -e reboot command

Method 2: Installing the APK to the User partition and then “moving” it to the System partition

Step 1: Similar to Method 1, for the sake of cleanliness, I suggest creating a folder in the /system/app partition. Use the mkdir command as described at the beginning of the instructions for Method 1. (Obviously,  before doing this, you should ensure that you started the emulator with the -writable-system directive, and used adb -e remount so that you can eventually have the /system partition as writable)

Step 2: Install the APK normally (from wherever it is, e.g on your computer, the SD Card etc) into the User partition of your device, using adb.

adb -e install <APK_FILE_PATH>

E.g: adb -e install C:\Users\user1\Desktop\myApp.apk

Step 3: Using adb get into the application installation directory and view how the APK was installed.

adb -e shell

cd /data/data/<APK_PACKAGE_NAME>

ls -al

E.g. adb -e /data/data/com.myPackage.package_name

In this directory you will probably see a couple of things including a /cache directory, a files directory, “split files” and a /lib directory (sym link) either to the /data/app-lib/ directory /vendor/lib/ or /system/lib/. You might also see /logs, /requests, /no_backup and /shared_prefs directories.

In my case i had a “base.apk” file, a /lib directory and lots of “split files” labelled split-lib-dependencies_apk.apk and split-lib-slice_0_apk.apk (numbered 0 to 9)

Step 4: Copy all the files from the installation directory in the User partition to the installation directory in the /system partition

In this step i opted to copy (using cp), rather than move (using mv) because mv was causing some unknown errors and i’ve read in some places something about problems with mv when trying to move directories across different partitions.

Since i was using cp i also elected to delete the directories and files in the user partition just after the copy was complete so as to mimic what i think should happen in a “move” operation.

Assuming you’re still in the installation directory in the User partition (from the previous step)

cp *.* /system/app/<APK_PACKAGE_NAME>/


cp *.* /system/app/com.myPackage.package_name/

If you want, you can check both the directories just to confirm that they look the same in terms of the copy being complete. In general if there were no errors, then the copy should have happened successfully.

cd /data/data/<APK_PACKAGE_NAME>/
ls -al
cd /system/app/<APK_PACKAGE_NAME>/

Since the directory in the system partition is created as root it will likely have permissions set to 777 i.e. rwxrwxrwx . For security reasons it’s better to change these to something lower. I’m not exactly sure to what exactly, because some resources suggest 644 (i.e. rw-r--r--), while I think 755 (i.e rwxr-xr-x)is what is needed. All the same, change them:

chmod 755 /system/app/<PACKAGE_NAME_DIR>


Note on Native Libraries:

If you have some native libraries built and deployed with your code (or in the APK that you’re trying to install as a system app), you will need to copy them either from within the APK file, by unzipping it’s contents, going into the /lib directory, into the folder that is named after the CPU architecture that your emulator or device is using (i.e. x86, x86-64, armeabi, etc); or from your compiled code (probably in <PROJECT_DIR>/app/build/intermediates/cmake/debug/obj if it’s a normal shared object library, or   <PROJECT_DIR>/app/src/main/assets/ if it is bundled as an ‘asset’) [*not sure if this asset part is actually true or necessary, but the *.so file for sure]

Alternatively if you had a /data/app-lib directory when you installed the APK in the user partition, you might find the library there.

The location you will probably have to copy the library to is either /system/lib/ or /vendor/lib/ (in some recent versions it is /system/vendor/lib ). You’ll notice in these directories the shared object library files (*.so) just sit there directly (no directory named according to the a package name)

You can copy from your device to the emulator using the adb -e push command


adb -e push C:\Users\user1\Desktop\Unzipped_APK_Dir\lib\ /system/lib/


adb -e shell

cp /data/app-lib/ /system/lib/

or from wherever else, probably with cp

Once you are happy that all the copy events completed successfully, you can go to the APK installation in the user directory , list the contents of the APK installation directory in order to see the package that you want to remove and use that name when deleting the directory

cd /data/data/
ls -al


rm -r com.myPackage.package_name

Now you can reboot your device either with the adb -e reboot command, or through the Power Button, on the Emulator GUI.

On reboot your app should be installed. Try opening it. If it opens successfully (which was my case), then we’re all good. You can also try holding the App’s icon and if it is installed as a system app then you shouldn’t be able (as a normal user) to see the Remove/Uninstall dialog that usually appears at the top for other apps.

Extra Note: From the Android Platform Code documentation on Github [3]:

Parser for package files (APKs) on disk. This supports apps packaged either as a single “monolithic” APK, or apps packaged as a “cluster” of multiple APKs in a single directory.

Apps packaged as multiple APKs always consist of a single “base” APK (with a {@code null} split name) and zero or more “split” APKs (with unique split names). Any subset of those split APKs are a valid install, as long as the following constraints are met:

  • All APKs must have the exact same package name, version code, and signing certificates.
  • All APKs must have unique split names.
  • All installations must contain a single base APK.

















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]


Installing the Google Play Store App (APK) on the Android Emulator

January 17, 2017 12 comments

This has been tested on the Android Emulator that comes default installed with the Android SDK with Android Studio 2.2.3.

The Android OS version used was the latest Android 7.1.1 (Nougat) and the Google Play APK version was 10.0.84 from OpenGapps (although I think any latest versions of the APK should work).

The basic idea from this post was adapted from a StackOverflow post [1] that had good ideas, but I had to tweak them to get it to work for my case.

TL;DR: The basic idea is that you need to get the APK files put them in the right location of the system partition (after getting it to be writable). Then giving the APK’s the right permisions (I gave them all 777, i don’t know why, i just wanted it to work, but perhaps not so good for security. May be 755 will also work.). Then reboot, once rebooted shutdown the instance, delete the Emulator instance from the Android Virtual Device manager, and clone another image out of the one that was written to. (If you didn’t get that … all the details are below…)


To get just the Google Play APK and it’s related services select the Pico version from the OpenGapps website. If you want other Google Apps also e.g. Gmail, Google Now, Google Music, Calendar, Youtube, etc you’ll have to select one of the other OpenGapps packages that has the apps you want.

Getting the APKs out of the OpenGapps ZIP (and TAR.LZ) archive

For this part you’ll need something that can open ZIP files and decompress the LZIP format. On Windows i used 7Zip and Lzip

I used the Windows batch script below found at the StackOverflow question cited[1] and created a batch file called unzip_gapps.bat. Make sure to change the line lzip -d GAPPS\Core\gmscore-x86_64.tar.lz to the file for which ever version of architecture you’re using, in my case it was x86 instead of x86_64

Put all the files (open_gapps-*.zip, 7z.exe, lzip.exe, unzip_gapps.bat) into a single directory and run the batch file.

@echo off
echo #################################
echo Extracting Gapps...
echo #################################
7z x -y open_gapps-*.zip -oGAPPS

echo Extracting Lzips...
lzip -d GAPPS\Core\gmscore-x86_64.tar.lz
lzip -d GAPPS\Core\gsfcore-all.tar.lz
lzip -d GAPPS\Core\gsflogin-all.tar.lz
lzip -d GAPPS\Core\vending-all.tar.lz

move GAPPS\Core\*.tar

echo #################################
echo Extracting tars...
echo #################################

7z e -y -r *.tar *.apk

echo #################################
echo Cleaning up...
echo #################################
rmdir /S /Q GAPPS
del *.tar

echo #################################
echo All done! Press any key to close.
echo #################################

The APK files should now be extracted and “automagically” appear in the directory.

Putting the APK’s in the right place on the Android device

NB: This needs some form of getting the /system partition (directory) to be writable, or to have root access in order to make the /System partition writable. I’ve seen some form of attempt at rooting the emulator here, in order to make the /system partition writable, but this didn’t do the trick for me.

Assuming that you have Android Studio, the SDK and an Emulator instance created with Android 7.1.1 (API 25), I had to start the emulator from the CLI with the directive writable-system


 emulator.exe -avd <Emulator_Instance_Name> -writable-system 


./emulator -avd <Emulator_Instance_Name> -writable-system 

Now the APK’s need to be put into the /system/priv-app/ directory, inside directories, each with the specific name of the APK it contains. You’ll probably  need root privileges to write to the system/priv-app directory. I used adb root to grant me root access. For some reason I also needed to to adb remount  to make sure that the /system partition becomes writable (Not sure why, if i already asked the emulator to have a writable /system partition, but this had to be done).  For subsequent accesses you can also get into the shell using adb shell and then from there switch user to root with su root.

NB: You might already have the directories PrebuiltGmsCore, GoogleServicesFramework, GoogleLoginService. (Unlikely you’ll have Phonesky). But create whichever ones you need as seen below.

adb root
adb remount
adb shell

cd /system/priv-app

mkdir PrebuiltGmsCore

mkdir GoogleServicesFramework

mkdir GoogleLoginService

mkdir Phonesky

Exit the ADB shell. Now we need to Push the right APK files to the right directories:

 adb push <APK_file_path> /system/priv-app/<Destination_dir>/ 


On Windows:

adb push C:\OpenGapps\PrebuiltGmsCore.apk /system/priv-app/PrebuiltGmsCore/

adb push C:\OpenGapps\GoogleServicesFramework.apk /system/priv-app/GoogleServicesFramework/

adb push C:\OpenGapps\GoogleLoginService.apk /system/priv-app/GoogleLoginService/

adb push C:\OpenGapps\Phonesky.apk /system/priv-app/Phonesky/

On Ubuntu:

./adb push ~/User1/OpenGapps/PrebuiltGmsCore.apk /system/priv-app/PrebuiltGmsCore/

./adb push ~/User1/OpenGapps/GoogleServicesFramework.apk /system/priv-app/GoogleServicesFramework/

./adb push ~/User1/OpenGapps/GoogleLoginService.apk /system/priv-app/GoogleLoginService/

./adb push ~/User1/OpenGapps/Phonesky.apk /system/priv-app/Phonesky/

Changing the Permissions of the APKs

Now you’ll need root access again to change the APK permissions. As mentioned earlier, i gave the permissions 777 to the files, but i’m not sure whether such high permissions are needed for all users, i think 755 might be more appropriate, but i haven’t tested this.

adb root

adb shell

chmod 777 /system/priv-app/PrebuiltGmsCore/PrebuiltGmsCore.apk

chmod 777 /system/priv-app/GoogleServicesFramework/GoogleServicesFramework.apk

chmod 777 /system/priv-app/GoogleLoginService/GoogleLoginService.apk

chmod 777 /system/priv-app/Phonesky/Phonesky.apk

At this point the APK’s might start installing themselves and you might get an error saying the Play Services have stopped or has stopped, or something close to that. Ignore it.

[Before April 2017, the rest of this guide was relevant, from April 2017, you don’t need to do the rest. Restarting the emulator should work.]

Restarting and Creating another Image 

(For Emulator versions, below v25, that is: Before April 2017)

Restart the Emulator and even now you’ll probably still be getting the Play Services have stopped or has stopped or something close to that.

Now shutdown the emulator normally, using the power button long-press.

After it has shutdown, go to the Android Virtual Device (AVD) manager through Android Studio (Tools > Android > AVD Manager). Delete the Virtual Device Instance and create a new one (this sounds counter intuitive, but if you check the time-stamps of the system image where these devices are cloned from [ {android_version_home_dir}/sdk/system-images/{android-version-number}/system.img> ]  you’ll notice that the system was written to pretty recently). This is because  we had the writable-system directive when we were making the changes, thus the Play Store APK got installed to /system partition “permanently”, so any new AVD created for this particular version of Android, it will have the Google Play Store APK installed properly.

Create a new AVD from the modified system-image android version and you’ll see the Play Store App installed, ready and waiting on the home screen.



Android Process Memory Dumps with memfetch – Android 4.4.2 (on Ubuntu 16.04)

December 25, 2016 Leave a comment

I used 2 different C code scripts to achieve the same goal of achieving the process memory dump. The specific code scripts are referred to as Memfetch (by Michal Zalewski – found on his blog) and Memdump (by Tal Aloni – found on StackExchange)

Update [2017-01-16]: I’m not sure whether this will work for Android on both x86 and ARM architectures. I tested it on an ARM architecture (physical device), and it worked. I’m yet to test it on an x86 architecture. Will update after testing.


Find the code from the author’s webpage here –

Unzip/Extract the code from the TarGZ archive

 tar -xvf memfetch.tgz 

Get into the directory:

cd memfetch

Use the ls command to list the files. The files should be listed as below:

COPYING   Makefile   memfetch.c   README

Now install the gcc compiler for Android on ARM (not sure if this is what it’s described as):

 sudo apt-get install gcc-arm-linux-android-eabi 

(some instructions say use the gcc-arm-linux-gnueabi but this didn’t work for me )

Edit the Makefile

Normally at this point you should be able to run the make command and compiling should work, however in Ubuntu the Canonical developers seem to have moved some key .h source files around causing problems. The first file that might cause problems if you run the make command will probably be  this is because Ubuntu has moved them from the original location of /usr/include/asm to be in the kernel source files /usr/src/linux-headers-[your-specific-kernel]/include/asm-generic

Make sure you’ve installed build-essential for this path to be existent

 sudo apt-get install build-essential 

You can get to the correct path with:

cd /usr/src/linux-headers-$(uname -r)/include/asm-generic

Once you locate the asm-generic folder check that the page.h file is present.

Now the best way to solve this problem is to create a symbolic link (symlink) in /usr/include/ called asm that links to /usr/src/linux-headers-[your-specific-kernel]/include/asm-generic/ . This is done with the following command:

sudo ln -s  /usr/src/linux-headers-$(uname -r)/include/asm-generic  /usr/include/asm 

Even with this, there will still be some problems because there are some .h files in asm-generic that will be looking for asm-generic in /usr/include/ where the folder doesn’t actually have those header files. So an extra include (-I) directive will need to be added in the Makefile

The beginning of your make file should look like this:

FILE = memfetch
CFLAGS = -Wall -O9 -static
CC = arm-linux-androideabi-gcc

NB: its a capital ‘O’ not a zero, and it’s a 9 (nine), not a ‘g’. The “O” “9” directive is some optimization thing (i don’t know if it’s necessary or not)

Run make at this point. If it works, then great, you should get a memfetch executable file in your memfetch directory if not, follow on.

If you run make and you still get errors of missing .h files, what i did was to just copy the files from /usr/src/linux-headers-$(uname -r)/include/asm-generic  to /usr/include/


 sudo cp /usr/src/linux-headers-$(uname -r)/include/asm-generic/memory_model.h  /usr/include/asm-generic/memory_model.h

The following files were missing …

  • getorder.h
  • /linux/compiler.h
  • /linux/log2.h
  • /linux/bitops.h
  • /linux/irqflags.h
  • /linux/typecheck.h

At this point i got more files in /bitops that were missing, so i decided to copy the entire directory :

cd  /usr/include/asm-generic
sudo mkdir bitops
sudo cp /usr/src/linux-headers-$(uname -r)/include/asm-generic/bitops/* /usr/include/asm-generic/bitops/

At this point i finally ran the make command in the the memfetch directory and an executable was created. There were a couple of warnings, but no errors and the executable worked when I pushed into onto the Android device.

Pushing to the Android Device and Executing “Memfetch”:

NB: We are assuming that the device is properly rooted, and the setting for giving adb shell root permissions has been set in your “Super User” management app.

Go to the adbexecutable location, which might be /home/Android/Sdk/platform-tools it could also be elsewhere … depending on where you installed it

cd /home/Android/Sdk/platform-tools

The best location to push the executable is /data/local/tmp. Let’s create a directory in this location and use the adb push command to push the executable here

./adb shell
su root
cd /data/local/tmp
mkdir mem_dump_tools

We exited first all the way out so that we can run the ./adb push command

./adb push ~/Desktop/memfetch/memfetch /data/local/tmp/mem_dump_tools/

Verify that the memfetch executable has been pushed to the right location:

./adb shell
su root
cd /data/local/tmp/mem_dump_tools
ls -al

The memfetch executable should be in place however it cannot be executed because it does not have execute permissions. We can give it execute permissions with the following command (assuming we are still the root user)

chmod 755 memfetch

(As a side note: chmod u+x memfetch should also work.)

Verify that the Execute permissions have been applied

ls -al

You should see rwx against the name of the memfetch executable. (The x being the important thing)

Now if we run a particular app and search this process’ ID we can dump the process memory. Pick an app e.g. Google Chrome and fire it. Browse to some page

On the adb shell:

ps | grep chrome

You should get 1-3 processes with Chrome (one with sandboxed and another with privileged attached to the process name). Pick the process ID of the process that is plain

Now we can run memfetch


e.g: ./memfetch 2314 if the process id is “2314”

You should now get some output to screen showing that the memory-mapped regions are being copied. The result is that for each address range (block) from the /proc//mem folder there is a sub folder called map that contains the mappings. These mappings result in an individual “region dump” per file (with a .bin extension) and each region dump filename is appended into a single file with a /lst extension containing all the filenames of all the regions dumped. So the end result is a lot of .bin files and a single .lst file.

NB: If at this point when you try to run memfetch  and all you get is a listing of the available options/directives, and nothing else, then you need to comment out some section of the code in memfetch.c and recompile. I don’t know why this is the case, but someone on StackExchange [2] figured this out and it also worked for me.

The lines to comment out are:

while ((opt=getopt(argc,(void*)argv, "+samwS:h"))!=EOF)
       case 's': waitsig=1; break;
       case 'a': skipmap=1; break;
       case 'w': textout=1; break;
       case 'm': avoid_mmap=1; break;
       case 'S': if (sscanf(optarg,"%x",&onlyseg)!=1)
            fatal("Incorrect -S syntax (hex address expected).\n");
       default: usage(argv[0]); }

With that, everything should work.

This blog post has become too long, so i’ll do memdump in the next one …




Android Process Memory Dumps – Notes

December 24, 2016 Leave a comment

Disclaimer: I don’t really understand everything about the workings of RAM memory and the OS. These are just my notes on how i got RAM Process Memory Dumps of Android Apps.


Capturing the process memory from a specific running process (application) in Android seems to have been more difficult that I thought. That’s probably because of the way Android is built that processes run under their own individual users and their respecting permissions.

Reading directly from /proc/<pid>/mem also seems to have been hindered since a process cannot read another process’ memory in Android (i think in some other Unix/Linux distributions at least reading seems to be possible)

A lot of sources talk about capturing “heap” dumps, but i wanted the entire process memory including the stack, the instructions (and essentially anything else). Heap dumps can be acquired through the DDMS tool in Android Studio (and somehow similarly in Eclipse also). The basic idea is that Android Studio provides RAM profiling tools for analyzing app runtime behaviour.

You can take heap dump from DDMS. According to most sources, it seems it needs to be converted from the default HPROF format to something that can be analyzed by the Java MAT tool (i’m not sure but i think DDMS now does all this automatically for you).

What I wanted was a full memory dump of the process and I couldn’t seem to find a way except through using the memfetch tool (by Michal Zalewski) compiled for Android or some smartly written script called memdump (by Tal Aloni) found on StackExchange.

Both scripts are written in C, so I had to compile them for Android and get them running on a phone in order to achieve my goal … and how this was done is the subject of the next post.

Major Sources:

[1]. Sylve, J., Case, A., Marziale, L., Richard, G.G.: Acquisition and analysis of volatile memory from android devices. Digital Investigation. 8, 175–184 (2012). here or here


[3]. (look for the memfetch code here)

Android FileSystem – Notes

December 19, 2016 Leave a comment

App Locations:

  • /system/apps – Pre-installed bloatware apps
  • /system/priv-apps – Privileged apps (mounted read-only to prevent changes)
  • /data/app – Normal apps in internal memory
  • /mnt/sdcard/.android_secure – Apps stored on external memory go into an encrypted container
    • /mnt/asec – These apps need to be decrypted to run, so during runtime they are found as a decrypted copy on a tmpfs here
    • This .android_secure container cannot be opened directly from the Android device, however if you plug the SD Card into another computer through a card reader, the .apk files now have the extension .asec connected to the same files on /mnt/asec
  • Nxt

App Data:

  • /data/data/<package_name> – Default location for application data on internal storage.
  • /mnt/sdcard/Android/data/<package_name> – Default location for application data on external storage (if the developer sticks to the rules outlined on the Android Developer Documentation here)

Binary Executable Test Locations:

  • /data/local/tmp – Location where you can put executables (NDK compiled / Linux ARM built)

Accessing the SDCard on the Emulator:

First make sure you’ve indicated that you want an SD Card for your Android Virtual Device in the AVD Manager while creating

  • You can find the path of your sd card with cat /proc/mounts and df -h
  • It should be at /mnt/media_rw/<8-Character-Serial-Number>
    • e.g. /mnt/media_rw/1CEF-2AB1