Sunday, 3 August 2014

What is the directory structure of android AOSP root tree?

This is short version of what you will find when you download the Android source. I will leave out some minor directories and dig deeper into a couple of the important ones. Basically what you will get (based on the (Kit Kat - 4.4.4), in alphabetical order:
  • Bionic - the C-runtime for Android. Note that Android is not using glibc like most Linux distributions. Instead the c-library is called bionic and is based mostly on BSD-derived sources. In this folder you will find the source for the c-library, math and other core runtime libraries.
  • Bootable - boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.
  • Build - the build system implementation including all the core make file templates. An important file here is the script that will help you a lot when working with the platform source. Running this script in a shell will enable commands to setup environment variables, build specific modules and grep in source code files.
  • Cts - the compatability tests. The test suite to ensure that a build complies with the Android specification.
  • Dalvik - the source code for the implementation of the Dalvik Virtual Machine
  • Development - projects related to development such as the source code for the sdk and ndk tools. Normally not a folder you touch when working with the platform for a target.
  • Device - product specific code for different devices. This is the place to find hardware modules for the different Nexus devices, build configurations and more.
  • External - contains source code for all external open source projects such as SQLite, Freetype and webkit.
  • Frameworks - this folder is essential to Android since it contains the sources for the framework. Here you will find the implementation of key services such as the System Server with the Package- and Activity managers. A lot of the mapping between the java application APIs and the native libraries is also done here.
  • Hardware - hardware related source code such as the Android hardware abstraction layer specification and implementation. This folder also contains the reference radio interface layer (to communicate with the modem side) implementation.
  • Kernel - not part of the default source download but you can get access to this code either by downloading it manually or by adding the repository to the repo tool. Contains the sources for the Android version of the Linux kernel.
  • Out - the build output will be placed here after you run make. The folder structure is out/target/product/. In the default build for the emulator the output will be placed in out/target/product/generic. This is where you will find the images used by the emulator to start (or to be downloaded and flashed to a device if you are building for a hardware target).
  • Packages - contains the source code for the default applications such as contacts, calendar, browser.
  • Prebuilt - contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
  • System - source code files for the core Android system. That is the minimal Linux system that is started before the Dalvik VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform

How To Run Compatibility Test Suite (CTS) ?

How does the CTS work?

The CTS is an automated testing harness that includes two major software components:

The CTS test harness runs on your desktop machine and manages test execution.

Individual test cases are executed on attached mobile devices or on an emulator. The test cases are written in Java as JUnit tests and packaged as Android .apk files to run on the actual device target.

Pre-Requirements :

  1. Linux System 
  2. Mobile or Emulator with User Build.
  3. Download latest CTS.
  4. Download CTS Media files.
  5. Download Android SDK for Linux and keep it ready. 

Setup the System for CTS:

1.Create 3 folders in your system root directory. 

  1. CTS
  2. CTS_Media
  3. ADT

2. Extract and Copy downloaded CTS files into the CTS folder which you have created now . It will have below folder structure 
3. Extract and Copy downloaded CTS Media files into the CTS_Media folder which you have created now .It will have below folder structure 
        1. Change the permission for file
                $ export chmod 544

4.  Extract and Copy downloaded android-adt files into the ADT folder which you have created now .It will have below folder structure 

5. Open Terminal and Set ADT path by running below command form root directory.

    $ export PATH=$PATH:/home/root/ADT/android-sdk-linux/sdk/platform-toots
    Note : Run any adb command to check path is set properly or not. (exp:  adb devices )

Set up the Device/Emulator :

CTS can be executed only on consumer devices. This section is important as not following these instructions will lead to test timeouts/ failures:
1. Your device should be running a user build (Android 4.0 and later)from
2. Please refer to this link on the Android developer site and set up your device accordingly.
3. Make sure that your device has been flashed with a user build (Android 4.0 and later) before you run CTS.
4. You need to ensure the Text To Speech files are installed on the device. You can check via Settings > Speech synthesis > Install voice data before running CTS tests. (Note that this assumes you have Android Market installed on the device, if not you will need to install the files manually via adb)
5. Make sure the device has a SD card plugged in and the card is empty. Warning: CTS may modify/erase data on the SD card plugged in to the device.
6. Do a factory data reset on the device (Settings > storage > Factory data reset). Warning: This will erase all user data from the device.
7. Make sure no lock pattern is set on the device (Settings > Security > Screen Lock should be 'None').
8. Make sure the "USB Debugging" development option is checked (Settings > Developer options > USB debugging). Google Confidential
9. Make sure Settings > Developer options > Stay Awake is checked
10. Make sure Settings > Developer options > Allow mock locations is checked
11. Make sure device is connected to a functioning Wi-Fi network (Settings > Wi-Fi)
12. Make sure the device is at the home screen at the start of CTS (Press the home button).
13. While a device is running tests, it must not be used for any other tasks.
14. Do not press any keys on the device while CTS is running. Pressing keys or touching the screen of a test device will interfere with the running tests and may lead to test failures.
15. Set up accessibility tests:
   1. adb install CTS/android-cts/repository/testcases/ CtsDelegatingAccessibilityService.apk
   2.On the device, enable Settings > Accessibility > Delegating Accessibility Service
16. Set up device administration tests: 
  1. adb install CTS/android-cts/repository/testcases/CtsDeviceAdmin.apk
  2. On the device, enable Settings > Security > Device Administrators > android.deviceadmin.cts.CtsDeviceAdmin* settings

17. Copy the CTS media files to your device using ADB with the instructions below:
   The CTS media stress tests require video clips to be on external storage (/sdcard). Most of the clips are from Big Buck Bunny which is copyrighted by the Blender Foundation under the Creative Commons Attribution 3.0license. The required space depends on the maximum video playback resolution supported by the device. By default, 176x144 and 480x360 SHOULD be supported. Note that the video playback capabilities of the device under test will be checked via the APIs.
Here are the storage requirements by maximum video playback resolution:
  • 480x360: 91.4MB
  • 720x480: 151.9MB
  • 1280x720: 401.6MB
  • 920x1080: 1008.2MB

Instructions to copy the media files to a device:
  • To copy clips for just the default resolutions, run ./ Google Confidential 
  • To copy clips up to a resolution of 720x480, run ./ 720x480. 
  • If you are not sure about the maximum resolution, try 1920x1080 so that all files are copied. ○ If there are multiple devices under adb, add -s serial option to the end. 
Syntax  :  $.<space>./CTS_Media/ <resolution>
Example :  $. ./CTS_Media/ 1920x1080

For example, to copy up to 720x480 to device with serial 1234567, run 720x480 -s 1234567.
Now , Start Using CTS commands :

1. Run the below command to start cts . 
   Syntax  $./CTS/tools/cts-treadfed run cts --plan <plan-name>
   Command $./CTS/tools/cts-treadfed run cts --plan CTS
     Note : It will take around 10 hours to complete test and it will create report in CTS/android-cts/repository/results folder.  To list the reports follow the below step.

2. Run the below command to list results . 
   Command $./CTS/tools/cts-treadfed list results
      Results will be shown as below :

3. Run the below command to continue the session if there is a "NotExecuted" cases  . 
      Syntax   $./CTS/tools/cts-treadfed add derivedplan --p <new-plan-name> --s <session-id> --r notexecuted
   Command $./CTS/tools/cts-treadfed add derivedplan --p CTS-FAIL --s 0 --r notexecuted

4. Run the below command to create new plan with Failed cases . 
      Syntax   $./CTS/tools/cts-treadfed add derivedplan --p <new-plan-name> --s <session-id> --r fail 
   Command $./CTS/tools/cts-treadfed add derivedplan --p CTS-FAIL --s 0 --r fail

5. Run the below command to create new plan with Passed cases . 
       Syntax   $./CTS/tools/cts-treadfed add derivedplan --p <new-plan-name> --s <session-id> --r pass
   Command $./CTS/tools/cts-treadfed add derivedplan --p CTS-FAIL --s 0 --r pass

6. Run the below command to run individual methods in class . 
       Syntax   $./CTS/tools/cts-treadfed run cts --class <class-name> --method <method-name>
      Command $./CTS/tools/cts-treadfed run cts --class android.permission.cts.FileSystemPermissionTest --method testOtherRandomDirectoriesNotWritable

7. Run the below command to run all methods in class . 
       Syntax   $./CTS/tools/cts-treadfed run cts -c <class-name>
       Command $./CTS/tools/cts-treadfed run cts -c android.permission.cts.FileSystemPermissionTest

Wednesday, 6 February 2013

NFC : Reading a MiFare Classic 1K from Android Devices

Ever since Near Field Communication was embedded on mobile phones, loads of new ideas and business proposals made people very busy. So does the Android platform with its API's supporting NFC. Nexus S looks like a state of the art - good starting point if one wants to get past the monotonic Nokia's piece of the cake. I just want to share with you my experience on reading a MiFare Classic tag using the Nexus S..and the Android platform. 

You need to have:
A MiFare Classic 1k Tag - ( hopefully you know the keys for its Blocks :=) )
Android SDK and IDE
Preferable a Nexus S (Make sure if the Android version is 2.3.3 and above).

Some Basics about the card:
MiFare classic cards store data in its Sectors. In MiFare classic 1k card there are 16 of them. Each Sector contains 4 blocks.  You can store 16 bytes in each block. Making about 1024 bytes of storage space..that explains the 1K part of the card. You can perform common tasks like reading, writing data on these blocks, authentification, navigating the card sectors by incrementing the blocks count. The first sector contains manufacturer’s details and a unique id for the card. This is a read only part.

Each sector on the Mifare card is secured by two 48-bit keys: A and B. The last block in the sector contains these keys, as well as a configuration that defines what each key can do with each block, i.e block 0 could be configured so that
key A could read and write, but if a reader authenticates with key B, the reader would only be able to read that block.

The rest of the memory storage can be read or written using keys A and B. Fresh, empty Mifare cards have all their sectors locked with a pair of default keys FFFFFFFFFFFF or 000000000000. 

Default Keys from experiments

About the NFC part of Android
Since ver 2.3.3 Gingerbread - Android exposes an API to read a list of card technologies. To perform operations on a tag, there are three things to be noted.

1) The cards store data in a format,
2) Reading and Writing data is done using a protocol
3) Cards support a technology that defines what they are 

hence reading and writing to these cards can be done only when the data is arranged in that format. MiFare 1K cards support the NDEF format. It also supports NFC - protocol on the communication level. Precisely - ISO 14443 - 3A specification in short NFCA and it uses the MiFare technology.

Now we need to let the Android know what kind of cards we would be using in our application. This is often defined in an XML file stored in the resource folder ( I have named the file - filter_nfc.xml and stored it in a folder named xml). This resource file contains for example,

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">

You would then set the permissions on your Manifest file.

<uses-permission android:name="android.permission.NFC"/>

You can also do this in your onCreate method by using an NfcAdapter,

 NfcAdapter mAdapter = NfcAdapter.getDefaultAdapter(this);

When a MiFare tag is discovered, the NFC stack would get the details of the tag and deliver it to a new Intent of this same activity. Hence to handle this, we would need an instance of the  PendingIntent from the current activity.

PendingIntent mPendingIntent = PendingIntent.getActivity(this, 0,
                new Intent(this, getClass()).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0);

Then we could set up our filter which defines the data format and technology type.

IntentFilter ndef = new IntentFilter(NfcAdapter.ACTION_TECH_DISCOVERED);
        try {
        } catch (MalformedMimeTypeException e) {
            throw new RuntimeException("fail", e);
        mFilters = new IntentFilter[] {

        // Setup a tech list for all NfcF tags
        mTechLists = new String[][] { new String[] { MifareClassic.class.getName() } };
        Intent intent = getIntent();

Finally when the pending intent calls the activity again, we like to read the tag. I have put all the steps in the method resolveIntent which would do only the reading part of the tag.


Reading the tag
The method looks like

private void resolveIntent(Intent intent){
 1) Parse the intent and get the action that triggered this intent
 2) Check if it was triggered by a tag discovered interruption.
 3) Get an instance of the TAG from the NfcAdapter
 4) Get an instance of the Mifare classic card from this TAG instance
 5) Connect to card and get the number of sectors this card has..and loop thru these sectors
 6) In each sector - get the block count, loop thru the blocks, authenticate the sector and read the data
 7) Convert the data into a string from Hex format.

filling up with the Android NFC API's

void resolveIntent(Intent intent) {
        // 1) Parse the intent and get the action that triggered this intent
        String action = intent.getAction();
        // 2) Check if it was triggered by a tag discovered interruption.
        if (NfcAdapter.ACTION_TECH_DISCOVERED.equals(action)) {
            //  3) Get an instance of the TAG from the NfcAdapter
            Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
            // 4) Get an instance of the Mifare classic card from this TAG intent
            MifareClassic mfc = MifareClassic.get(tagFromIntent);
            byte[] data;
            try {       //  5.1) Connect to card 
            boolean auth = false;
            String cardData = null;
            // 5.2) and get the number of sectors this card has..and loop thru these sectors
            int secCount = mfc.getSectorCount();
            int bCount = 0;
            int bIndex = 0;
            for(int j = 0; j < secCount; j++){
                // 6.1) authenticate the sector
                auth = mfc.authenticateSectorWithKeyA(j, MifareClassic.KEY_DEFAULT);
                    // 6.2) In each sector - get the block count
                    bCount = mfc.getBlockCountInSector(j);
                    bIndex = 0;
                    for(int i = 0; i < bCount; i++){
                        bIndex = mfc.sectorToBlock(j);
                        // 6.3) Read the block
                        data = mfc.readBlock(bIndex);   
                        // 7) Convert the data into a string from Hex format.               
                        Log.i(TAG, getHexString(data, data.length));
                }else{ // Authentication failed - Handle it
        }catch (IOException e) {
                Log.e(TAG, e.getLocalizedMessage());
    }// End of method

you would have to think about how you like to handle the lifecycle of this activity. I Like to call the reading part of the activity when I detect a tag and if on pause.. would like to disable this. It has been very neatly explained in the Android samples on Foreground dispatch.. I have added this part of the code here too,

        public void onResume() {
            mAdapter.enableForegroundDispatch(this, mPendingIntent, mFilters, mTechLists);

        public void onNewIntent(Intent intent) {
            Log.i("Foreground dispatch", "Discovered tag with intent: " + intent);

        public void onPause() {