Menu Bar

Friday, 10 October 2014

Setting up ADB On Ubuntu Linux

 

 

If you are like me and like developing in Linux, then you will find this guide useful. When I was setting up everything for my Android development, I ran into the problem that Linux was not recognizing my Android phone, and took me some time figuring out how to make Linux recognize my phone. Finally, after some research I was able to put this little guide together and decided to share it with the rest of the world.
ADB (Android Debug Bridge) is a handy tool that comes with Android SDK that allows you to control and interface with your Android device.

Update: 07/29/13 – In step 4, Android 4.2.x and up has Developer Options hidden. Added steps to make it visible
Update: 05/27/13 – Updated platform-tools (ADB) to latest version (Revision 17)
Update: 02/04/11 – HTC changed its Vendor ID, older phones have different ID than newer phones. Refer to USB Vendor IDs table at the bottom of this tutorial to see the change.
Update: 01/02/11 – By mistake I had linked the ADB tool for OSX in step 3.1. Now it should be the correct one for Linux.
IMPORTANT Update 12/11/10 – There has been a change to the new Android SDK. ADB Tool has been moved to /android-sdk-linux_x86/plataform-tools, so if you have the old SDK, please download the new one and update your path (Step 9.2 of this tutorial). If this is your first time doing this, then disregard the update and continue with the tutorial.
Update: 09/21/10 – Working code with Ubuntu Lucid Lynx and added more USB vendor IDs.
  1. Download the latest Android SDK from Google: Android SDK
  2. Extract the TGZ file to your home/YOUR-USERNAME directory
  3. To get ADB, you need to install the SDK: Installing the SDK
    • If you are not a developer and not planning to develop, then just download the following zip file containing only the ADB tool and proceed with the tutorial: ADB
  4. On your phone, click Settings > Applications > Development and make sure USB Debugging is on.
    • In Android 4.2.x and up Developer Options is hidden, to make it visible, do the following
    • Tap seven times in Build Number: Settings > About Phone > Build Number
    • You will get a message saying you have enabled Developer Options or something like that, go back to Settings and you will see Developer Options in there.
  5. Login as root and create this file: /etc/udev/rules.d/##-android.rules
    NOTE: In the above file replace ## with the number 50 if you are running Gusty/Hardy/Dapper (50-android.rules) or with the number 70 if you are running Karmic Koala/Lucid Lynx/Maverick Meerkat(70-android.rules)
    • Or simply type in terminal sudo gedit /etc/udev/rules.d/##-android.rules then enter your password
  6. The file should read:
    • For Gusty/Hardy: SUBSYSTEM==”usb”, SYSFS{idVendor}==”0bb4″, MODE=”0666″
    • For Dapper: SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”0bb4″, MODE=”0666″
    • For Karmic Koala: SUBSYSTEM==”usb”, SYSFS{idVendor}==”0bb4″, MODE=”0666″
    • For Lucid Lynx: SUBSYSTEM==”usb”, SYSFS{idVendor}==”0bb4″, MODE=”0666″
    • For Maverick Meerkat: SUBSYSTEM==”usb”, ATTR{idVendor}==”0bb4″, MODE=”0666″
    NOTE: In the above lines the code ”0bb4″ refers to a HTC device. If your phone is from a different manufacturer, replace the code with the appropriate from the table below.
    NOTE: If you copy one of the lines mentioned above, make sure you replace the quotation marks with the ones in your keyboard, as these have different display code and it might give you a “no permissions” error.
  7. Execute: sudo chmod a+rx /etc/udev/rules.d/70-android.rules
  8. Reboot
  9. To run ADB you need to add an environment variable to your bashrc file:
    • Open a terminal window and type: sudo gedit .bashrc
    • Add the following line at the end: export PATH=${PATH}:/home/YOUR-USERNAME/android-sdk-linux_x86/platform-tools
    • Save and close
  10. You should be ready to go, type adb devices in a terminal window with your phone plugged in.
    If you see a serial number pop up that means you are done. Should look something like this:
    List of devices attached
    HT99PHF02521 device
  11. If for some reasons when running adb devices gives you a “no permissions” error, try typing the following in terminal
    • db kill-server
    • adb start-server
USB Vendor IDs
Manufacturer USB Vendor ID
Acer 0502
Dell 413c
Foxconn 0489
Garmin-Asus 091E
HTC (Older Phones) 0bb4
HTC (Newer phones) 18d1
Huawei 12d1
Kyocera 0482
LG 1004
Motorola 22b8
Nexus One/S 18d1
Nvidia 0955
Pantech 10A9
Samsung 04e8
Sharp 04dd
Sony Ericsson 0fce
ZTE 19D2

Common ADB Commands

– Lists which devices are currently attached to your computer
1adb devices
– Drops you into a basic linux command shell on your phone with no parameters, or lets you run commands directly
1adb shell
– Lets you install an Android application on your phone
1adb install
– Remounts your system in write mode – this lets you alter system files on your phone using ADB
1adb remount
– Rets you upload files to your phones filesystem
1adb push
– Lets you download files off your phones filesystem
1adb pull
– Starts dumping debugging information from your handset to the console – useful for debugging your apps
1adb logcat




------------------------------------------------------------------------------------------------------------------------------------

How to fix the adb no permissions error on Ubuntu Lucid

This blog post explains how to fix the no permissions error the Android Debugger displays when running the adb devices command Linux. The solutions presented here have been tested and found working on Ubuntu Lucid, but they should also work on other Ubuntu and Linux versions as well.
This official help center page has many working and non-working answers to the problem, and many comments. The root cause of the problem is that the current user doesn't have sufficient permissions to access the USB device file created when the phone was connected in USB debug mode.
Killing all running adb server instances with sudo killall adb, disconnecting the phone, reconnecting the phone, and then running sudo adb devices instead (so adb gets run as root) fixes the problem.
Alternatively, it is possible to implement a long-term fix which doesn't require sudo, thus it works with e.g. IntelliJ IDE integration:
  • Create a file named /tmp/android.rules with the following contents (hex vendor numbers were taken from the vendor list page):
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0e79", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0502", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0b05", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="413c", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0489", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="091e", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="24e3", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="2116", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0482", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="17ef", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="1004", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0409", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="2080", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0955", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="2257", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="10a9", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="1d4d", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0471", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="04da", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="05c6", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="1f53", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="04dd", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0fce", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="0930", MODE="0666"
    SUBSYSTEM=="usb", ATTRS{idVendor}=="19d2", MODE="0666"
  • Run the following commands (without the leading $):
    $ sudo cp /tmp/android.rules /etc/udev/rules.d/51-android.rules
    $ sudo chmod 644   /etc/udev/rules.d/51-android.rules
    $ sudo chown root. /etc/udev/rules.d/51-android.rules
    $ sudo service udev restart
    $ sudo killall adb
  • Disconnect the USB cable between the phone and the computer.
  • Reconnect the phone.
  • Run adb devices to confirm that now it has permission to access the phone.
Please note that it's possible to use , USER="$LOGINNAME" instead of , MODE="0666" in the .rules file, substituting $LOGINNAME for your login name, i.e. what id -nu prints.

Friday, 3 October 2014

Android Partitions (All u need to know)


While the specifications for a mobile device tell us about the size of internal storage, they do not tell us how the internal storage is partitioned. While it is possible to create multiple partitions on external storage, external SD cards normally have a single partition that is formatted with a single FAT32 file system. Consequently, the scope of this article is limited to internal storage. Unless you are installing a custom version of Android on your phone, you really do not have any choice as to the size of the partitions. Before discussing what you can do, we need to understand the Android partition scheme.

Advantages of Multiple Partitions

Partitions serve as a means of allocating space on physical media. While it is possible to create a single partition on internal storage, multiple partitions have the following advantages:
  • The two partitions that see regular change are data partition and the cache partition. The data directory stores all the Android application data, while the cache directory stores temporary data. For example, Web browsers store data from Web sites to reduce the transfer time, when accessing the same Web page. The one exception is the dalvik cache, which is part of the data directory. Java uses a JIT (Just-In-Time) compiler to translate the byte code into the machine code for the platform. By saving the compiled version in the Dalvik cache, the Dalvik VM (Virtual Machine) does not need to keep recompiling the application every time it is used. By having a separate partition, the growth of the cache directory is limited to the size of the partition. This, however, sets a limit to the number of applications that can be saved on the internal media.
  • The boot partitions, there may be one or more, are only required during the boot process, and are never mounted. By the same token, the recovery partition needs to be accessed only when performing a phone recovery.
  • Some partitions are mounted as read-only, such as the system partition. There is nothing in the system partition requires changing by a user. While this directory is important to the operation of an Android device, the files in this partition only change when the device is upgraded to another version of Android.
  • When you encrypt your phone, only the data partition is encrypted, since this is the only directory that contains user data. It is important to note that the entire partition is encrypted, and not individual files. Mounting of the partition requires the entry of the encryption password.
While partitions play an important role, identifying the partitions takes a bit of detective work.

Identifying the Partition Layout

While there are certain common partitions, there is no standard for partition layout or sizing. You will see different layouts in different versions of Android, and different layouts from different vendors. This article is based on the partition layouts for a Samsung Galaxy S III running Ice Cream Sandwich, an B&N Nook Color running CM 10, and a Jelly Bean emulator from the Android SDK. To explore your Android mobile device, you need to install the Android Terminal Emulator app, or use adb (Android Debug Bridge). Both require a fundamental knowledge of Linux commands.
While the mount command shows the mounted partitions, it does not show all the partitions. For a full list of partitions you can run the command: cat /proc/partitions. In addition to showing the device name, the file displays the size of each partition. The device names follow a naming format, such as mmcblk0 for the entire device. Each partition of the device then has the name such as mmcblk0p1 for the first partition on that block device. However, the device name tells you nothing about the contents of the partition. For some Android devices, you can find more information by using the following command:
ls -l /dev/block/platform/block_device_name/by-name/
For example on the Samsung Galaxy S III running Ice Cream Sandwich, the command is:
ls -l /dev/block/platform/dw_mmc/by-name/
The -l option is important as the partition name is a symbolic link to the actual device name, as shown below:
lrwxrwxrwx root root 2013-01-14 22:17 BOOT -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-01-14 22:17 BOTA0 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-01-14 22:17 BOTA1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-01-14 22:17 CACHE -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-01-14 22:17 EFS -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-01-14 22:17 HIDDEN -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2013-01-14 22:17 OTA -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2013-01-14 22:17 PARAM -> /dev/block/mmcblk0p4e
lrwxrwxrwx root root 2013-01-14 22:17 RADIO -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2013-01-14 22:17 RECOVERY -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-01-14 22:17 SYSTEM -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-01-14 22:17 USERDATA -> /dev/block/mmcblk0p12

If the by-name directory is not present, you only know the information provided in the mount command. While every block device is represented in the /sys/block directory, there is no attribute that displays the label on the partition. Alas, CM 10 does not provide the by-name directory. However, unlike most distributions of Android, it does provide a stripped down version of the fdisk command, which provides some useful information. To view the partition layout for the internal storage, use the following command:
fdisk -l /dev/block/mmcblk0
The results of the above command for CM 10 are as follows:
Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes
255 heads, 63 sectors/track, 965 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1   *           1           9       72261   c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2              10          18       72292+  c Win95 FAT32 (LBA)
/dev/block/mmcblk0p3              19          56      305235  83 Linux
/dev/block/mmcblk0p4              57         935     7060567+  5 Extended
/dev/block/mmcblk0p5              57         114      465853+ 83 Linux
/dev/block/mmcblk0p6             115         236      979933+ 83 Linux
/dev/block/mmcblk0p7             237         281      361431  83 Linux
/dev/block/mmcblk0p8             282         935     5253223+  c Win95 FAT32 (LBA)
 
The above output tells us a lot about the partition structure of Android. Partition 1 is the primary boot loader, while partition 2 is the alternate boot loader. Most Android devices have two boot loaders for reasons that are beyond the scope of this article. Partition 3 contains the boot kernel image. This partition never needs to be mounted, as the boot loader knows its location.
Android, like Linux, uses the standard MSDOS partition table, with a maximum of four primary partitions. Thus, partition 4 is the extended partition for the remaining logical partitions. The following table summarizes the information from the above commands:

Device
name
/dev/block
Samsung Galaxy SIII CyanogenMod 10 AOSP Emulator
boot mmcblk0p5 mmcblk0p1  
bootloader0 mmcblk0p1 mmcblk0boot1  
bootloader1 mmcblk0p2 mmcblk0boot2  
cache mmcblk0p8 mmcblk0p7 mtdblock2
efs mmcblk0p3 mmcblk0p4  
hidden mmcblk0p10    
emmc   mmcblk0p8  
data mmcblk0p12 mmcblk0p6 mtdblock1
ota mmcblk0p11    
param mmcblk0p4    
radio mmcblk0p7    
recovery mmcblk0p6 mmcblk0p1  
rom   mmcblk0p2  
system mmcblk0p9 mmcblk0p5 mtdblock0

If you are looking for a swap partition, there is none. The write activity to a swap partition would considerably shorten the life of the flash memory. Instead, Android uses a different technique that is actually more efficient than swapping. To understand why sdcard0 is not directly mounted, we need to understand more about the FUSE file system.

The FUSE File System

Prior to the Honeycomb version of Android, sdcard0 was mounted like the other partitions, and was formatted as a FAT32 partition. While it made USB tethering to a PC easy for file transfers, it presented a number of problems:
  1. You cannot mount a partition on two devices at the same time, as there is no shared mechanism for file locking. Thus, in versions of Android up through Gingerbread, the phone was suspended so that sdcard0 could be unmounted from the phone, and mounted to the PC, or any other device that supported USB connections.
  2. The Android device had to separate the data partition, which contained the Android apps, from the sdcard0 partition, which contained user data. This separation made partition sizing  an issue, as the developers had to create a balance between the maximum number of applications and the maximum amount of data. A side effect of this was for Android app developers to create directories on the external SD card that did not follow any standard naming conventions, and where never removed when the app was deleted.
  3. The FAT32 file system is a Microsoft proprietary standard. To avoid licensing issues and patent lawsuits, a new approach was required.
The decision was to use the FUSE (Filesystem in Userspace), since it was already a standard part of the Linux kernel. FUSE is a pseudo file system that provides a bridge to another file system for selected files. FUSE provides the following benefits:
  1. Files can be shared to other devices, while the Android device remains active. Thus, you have full use of your Android device, while transferring files. For example, you could use your phone as a media player, while talking on the phone, using GPS, or taking pictures. Instead of using USB mounts, files are transferred using MTP (Multimedia Transfer Protocol).
  2. FUSE allows a single partition for data and user files, as only selected  files are shared via FUSE. The Samsung Galaxy S III fully implements this concept, while CM 10  still maintains separate partitions on the B&N Nook Color.
  3. The data partition can be formatted with any file system, as FUSE hides the original file system. Thus eliminating the need to support FAT32 for the sake of file transfer. The standard is to format the data partition with the EXT4 file system.
There are a number of disadvantages to FUSE:
  1. The use of MTP requires a MTP compliant application on your PC. This should not be a problem with Microsoft Windows or MAC, but does present some challenges to a Linux user. In a future article, I will discuss file transfers using MTP.
  2. There appears to be a 1024 file limit to open files. I need to do some kernel research to find the parameter that sets this limit.
Creating a single data partition simplifies encryption of the data stored on internal storage.

Android Data Encryption

With the move away from FAT32 for user data storage, and the consolidation of user data and application into a single partition, Android can now go beyond simple encryption of  files. With the EXT4 file system, Android takes advantage of another Linux feature that allows for encryption of the entire file system. Android encryption uses the dm-crypt layer of the Linux kernel, which only works on block devices. The latter restriction excludes YAFFS as a file system, since it accesses internal storage as a character device, and not a block device.
Since the file system is encrypted, the kernel uses the dm virtual device to store the unencrypted version of a file. If you look at /proc/partitions, you may see loopback (loop) and dm virtual file systems. I separate virtual file systems from pseudo file systems in that a virtual file system is the backing store, and does represent a file system in memory. Using a bit of kernel magic, Linux keeps the unencrypted version of a file in a dm file system. The init.rc file divides the files into three classes: core, main, or late-state.
When you encrypt internal storage (only the data partition is encrypted), you must use password protection. The Google Android team chose to use a single password, instead of separate passwords. Ideally there should be an option for separate passwords for maximum security, but one password is not a huge security risk. Immediately after entering the SIM pin, the mobile device prompts you for your encryption password. If you don't know it, the mobile device cannot continue the boot process, as it cannot access the data partition. Since there is no longer a USB mount, even connecting the mobile device to a PC is not going to provide access to encrypted data. Even MTP access will fail, as FUSE requires access to the data partition.
Since external storage typically uses the FAT32 file system, encryption is limited to individual file encryption. Storing sensitive files on an external SD card does represent a security risk.

Managing User Files and Directories

The pre-installed File Manager app provides a limited view of the user viewable file structure. For many user this view is sufficient. However, the Storage Analyser app provides a much more complete view of both internal and external storage. The Storage Analyser app works on both rooted and non-rooted Android devices. Even on non-rooted devices, you have the option to see all mounted partitions, even though you do not have access to partitions such as /data. At least, you get to see how much space those partitions consume.
Storage Analyser also shows hidden files and directories, which you do not see in File Manager. A hidden file, or directory, is one that begins with a dot (.). For example, .android_secure is hidden directory. Hidden files are not new, as they are a common convention used in Linux and Unix. To hide any file, or directory, you just need to modify its name to begin with a dot.

Summary

The changes, which started to appear in Honeycomb, are not new to Linux. Android is just adopting these features to make your Android devices more flexible and secure. I highly recommend that everyone encrypt their internal storage to minimize the risk of data theft. Considering that Android mobile devices are really mobile computers, the small inconvenience of entering a password is minor compared to the exposure of all your accounts in case of loss or theft.

Sunday, 21 September 2014

Communication Mechanism of Android Processes


android-logo.png
In our previous article Android, at a glance we have covered how Android has appeared, explained its software structure and what has to be paid attention when developing apps for this platform. In this article, I will go further and discuss about the Binder, the core subsystem of the complex and huge Android platform. I will explain about different components provided in Binder, how application processes communicate with system processes, and how data is shared.
As hardware performance of smartphones, a so-called "PC in my hand," improves, they are taking over the roles of PCs. With the trend, mobile OS has also been enhanced to support multitasking and process a variety of multimedia tasks using multi-core CPUs. Most mobile operating systems are based on PC operating systems. Keeping the architecture of the existing PC OS, the kernel gets partially modified to meet the requirements of the mobile environment, and necessary functions are added for optimization. Window Phone based on MS Windows OS, iOS based on Mac OS X, Google Android based on Linux Kernel, are the most popular in this category.

Smartphone - A PC in My Hand ... PC OS in My Hand!

If you have questions like, "What will be modified if the PC OS is embedded into the smartphone, and how and why?", the open source Android platform can provide your with a pretty good answer. The Android platform is the result of the latest software technology; it provides a lot of information via its developers community and allows users to directly modify its open source code.
Android has inherited powerful base systems from Linux Kernel such as the memory management, multitasking and file management. In addition, it has lowered the entry barrier by providing various development tools used to develop Java applications based on the Dalvik VM. Since the base systems are implemented in C++, they come with highly productive code. Actually, the Android developers say that one of Android's benefits compared to the other embedded systems is C++.
Thus, Android is a platform which embraces numerous technologies like Linux Kernel, C++, Java, Dalvik VM, etc.
typical-schematic-of-android_structure.png

Whatever, it is a Linux Process!

Android provides the process-unit component model. In other words, system services which provide an application or a camera feature created in Java on Eclipse, or system services which are responsible for screen display, all such Android components are eventually expressed as Linux processes.
process_management_of_linux-kernel.png
Figure 2: Process Management of Linux Kernel.
Since Android runs based on Linux memory, process and file management, the system service is also isolated by Linux process for protection. The system process is written in Java code as well as C++ native code, so the services that run in Dalvik VM, such as Wi-Fi, Location and Activity Service, are included here.
To support mobile devices such as smartphones, all of the default system functions of Android are provided as the server process type. In other words, to use the functions such as SurfaceFlinger or AudioFlinger, a request should be made as a separate process that runs on the user mode.
android_system_services_and_applications_run_by_linux_process.png
Figure 3: Android System Services and Applications Run by Linux Process.
For example, when an application that I have created calls APIs to get the location information provided by the Android SDK, the application sends a request to the Linux process that provides the Location service internally and gets the response. Also, it interoperates with the camera service when a camera is used.
application_process_with_call_locations_service_and_camera_service.png
Figure 4: Application Process Which Calls Location and Camera Services.
As all system services are provided as a server process, a mechanism to send requests and responses to other processes is necessary. In Android it is called the Binder. Android uses functions provided by other processes through Binder.
binder_android_communication_infrastructure_between_processes.png
Figure 5: Binder, Android's Communication Infrastructure between Processes.
Then, why has a new mechanism been developed, rather than using Inter Process Communication (IPC), such as sockets and pipes provided by Linux? It is because of performance. As we have discussed above, all system functions of Android are provided as a server process, so an optimized communication method between processes is required, and Binder is the result of this consideration. Binder refers to a kernel memory which is shared between all processes to minimize the overhead caused by memory copy. In addition, it provides the Remote Procedure Call (RPC) framework written in C++ for high productivity.
The system functions are provided as server processes where requests and responses are received through the Binder mechanism. "What are the benefits of the Android platform structure?" you would ask.
  • Easy to expand or remove functions: It is easy to add a new system service or remove an existing function.
  • Easy to port: Porting to a new processor requires few changes. A toolchain for porting is provided.
  • Easy to test: Tests are limited by the component unit, so it is not necessary to test the entire services, and more strict tests are available.
  • Support for distribution system: Process communication is based on the Binder, so it guarantees transparency in location between components.
Such benefits are very similar to those of Microkernel structure OS.
Let's discuss more about the Binder.

Binder that Binds All Functions

The Binder mechanism has started from a simple idea. "Let requests and responses be written in an area where all processes can share and let each process refer to the memory address." So, the kernel space is used for it.
kernel_space_shared_by_all_processes.png
Figure 6: Kernel Space Shared by All Processes.
A Binder Driver is implemented to use the kernel space. The role of the Binder driver is to convert the memory address that each process has mapped with the memory address of the kernel space for reference.
binder_driver_configuration.png
Figure 7: Binder Driver Configuration.
The Binder driver can be used by the ioctl() system function, which is a standard method in Linux. The mechanism is called Binder IPC.
transfer_structure_of_user_data_between_processes_through_binder_driver.png
Figure 8: Transfer Structure of User Data between Processes through Binder Driver.
There is a C++ framework that processes the data transferred using the Binder IPC and makes Remote Procedure Call (RPC). It is used to create a system service. Then, a process can use functions provided by other processes as if their own.
c++framefork_that_transltes_data_translated_to_rpc_through_binder_driver.png
Figure 9: C++ Framework that Translates Data Translated to RPC through Binder Driver.

Conclusion

In this short article I have tried to provide only simple information despite the vast technology behind Android. I hope it will be helpful to you in understanding the Android platform.
To wrap up, Binder is the base of the Android platform. We have reviewed three components of Binder: Driver, IPC and RPC. The Binder Driver will be included in the main version of the Linux kernel. The following summarizes the description of Android and Binder.
  • Android is a PC OS based on Linux Kernel and is optimized for smartphones.
  • Android has a process-unit component model and provides system functions as server processes. For a functional mesh-up of processes, it provides Binder.
  • Android Binder uses the kernel memory reference to support communication between processes, optimized for mobile devices.

The Adroid System Overview

Android, at a glance


android-logo.png
Android, currently the most popular mobile operating system in the world, continues to further solidify its position as the major mobile platform in the world. In this article I will briefly cover how Android has appeared, and will explain its software structure and what has to be paid attention when developing apps for this platform.

What is Android?

Linux operating system is the main component in Android's software stack. It does not differ much from Microsoft's Windows OS or Apple's Mac OS which we use on the daily basis. Therefore, theoretically you can enjoy Android not only on mobile devices but also on other tablet devices as well just like Windows even to a point where various applications can be downloaded and used. Of course, if you want to make an Android application by yourself, you should also install ADK (Android Development Kit) to your PC and use Java programming language for development. For a lower level program, NDK (Native Development Kit) for C language shall be used.
It seemed that Android had been shunned publicly for not having as sensitive UI as iPhone. However, now it is considered as the most viable blue-chip mobile OS with advantageous openness, free, and Java-based characteristics.
Another interesting aspect is that most users mistakenly think that Android was developed by Google. In fact, it was developed in 2003 by "Android" company based in California. Back then, few people knew about it, even less developed for it. However, everything was changed in 2005 when Google acquired Android company to give birth to Android that we know now.

The History of Google Android

Since its initial release of 1.0 version in September 23rd, 2008, Android has enjoyed a remarkable growth. All versions until 3.0 (code name Honeycomb) are available under Apache free open source license. According toAndroid official blog, the source code of the Honeycomb series was not released to the public because it was specifically created for tablet computers, and Google did not want external developers to mess up the user interface by putting on smartphones a version of Android intended for tablets.
However, Google later announced that in the next 4.0 version, planned for the second half of this year (code nameIce Cream Sandwitch), Android will combine both the smartphone version (code name Gingerbread) and the tablet version (HoneyComb).
The first version of Android, released back in 2008, had drawbacks in many aspects. Some users voiced their worries about its terrible UI and development tools, saying “who would want to use it”. However with its advantage of using Java as SDK language and its openness Android gradually solidified itself as the most rapidly developing mobile OS, and it seems as if no one dare to challenge the idea that Android will further expand and attract more users than iPhone and be loaded onto more various mobile devices.
The following are the key functions of each Android version
  • 2.0, 2.1 (Eclair): Web browser supporting new UI and HTML5. Advanced camera app, new launcher app and weather app. Supports moving background.
  • 2.2 (Froyo) : Improved performance by optimizing JIT. Chrome V8 Javascript engine. Support Wi-fi hot spot tethering and Flash.
  • 2.3 (Gingerbread) : Optimized UI for minimum battery use. Enhanced soft keyboard, COPY/PASTE function, NFC (Near Field Communication, local network).
  • 3.0 (Honeycomb) : Support tablet screen. New UI and multi-core processor.
  • 3.2 (Honeycomb) : Compatible mode for zoom-to-fill screen. Read media file directly from SD card. Additional screen API. Controls UI more delicately.
  • 4.0 (Ice Cream Sandwich) : Combined version of Gingerbread and Honeycomb.

The Structure of Android

Android basically runs on DVM (Dalvik Virtual Machine) which is Android runtime loaded on Linux kernel. The figure below illustrates all the components. Further I will explain each of them from top to down.
typical-schematic-of-android_structure.png



ANDROID STRUCTURE

Applications

This domain is for applications developed with Java. Generally, email client, SMS program, calendar, browser and contacts applications are loaded.

Application Framework

Application framework provides all kinds of APIs needed to develop a full-featured application for Android platform. Using APIs in this domain allows to express buttons and text on the screen or use data of other applications such as images and character strings. Also it is possible to manage application’s lifecycle.

Libraries

This domain provides various C/C++ libraries which can be used on Android. All libraries in this domain can be used by developers via application framework. Standard C system libraries based on BSD (Berkeley Software Distribution) are revised to be suitable for Linux-based devices. Media library based on OpenCore of PacketVideo supports MPEG4, H.264, MP3, AAC, AMR, JPG and PNG files. Surface manager supports 2D and 3D graphics whileWebKit supports browser functions. SQLite is also available as a database engine which can be used by applications.

Android Runtime

Although Android is developed in Java language, DVM (Dalvik Virtual Machine) is used instead of JVM (Java Virtual Machine). Thus, a source code (Java) is compiled to a class file (.class) with Java compiler which is later transformed to Dalvik Executable by DX tools. The reason for this is that Dalvik is optimized to run on small sized devices with limited memory.

Linux Kernel

Android is developed based on Linux kernel 2.6 which provides high security, memory and process management, network stack and various drivers.

Android Project Structure

Android applications are developed in Java. However, unlike the desktop version of Java applications, the class files in Android applications are not loaded directly. Instead Android's development tools combine the resource files and DEX file transformed from class file to make APK. And this APK gets loaded.
Below is the basic directory structure for developing the Android application.
/assets Data files to be installed to device along with the application.
/bin Compiled application file.
/gen Resource reference files automatically created by the Android build system.
/res Resource files such as character strings and images to be used in the application.
/src Application source code.
AndroidManifest.xml Basic set file of application.
You need to make sure that files are stored in the right directory, particularly for resources. Since directories are already reserved, changing at your will would make directories difficult to recognize.

Resource Directory

Resource directory is composed of drawable directory for placing images and layout directory for putting the XML files to the layout. Raw and xml directories are not automatically created in the default project, so should be created manually.
/res/drawable-hdpi Image to be shown on hdpi.
/res/drawable-ldpi Image to be shown on ldpi.
/res/drawable-mdpi Image to be shown on mdpi.
/res/drawable-nodpi Image to be shown regardless of density.
/res/layout/ XML file defining UI layout.
/res/layout-port/ XML file defining UI layout (vertical mode).
/res/layout-land/ XML file defining UI layout (horizontal mode).
/res/menu/ XML file defining menus.
/res/values/ File defining various values such as character strings.
/res/xml/ Various files saved in the form of XML.
/res/raw/ Other files (mp3, mp4 and so on).
The vertical and horizontal mode differs in size on the phone screen. Therefore, if you need both of them to be shown identically, you need to create screen layout file on /res/layout/ directory. To show differently, create the layout in the layout-port (portrait) and layout-land (landscape) directories. Also, often you may need to create a layout and layout-land only. Then files in layout will be applied to vertical mode layout.

Result Directory

The structure of bin (result) directory is as follows.
bin/classes/ Compiled Java class.
bin/classes.dex Dalvik class file created with compiled Java class.
bin/resources.ap_ All resource files (zip) of application.
bin/app_name.apk Android application (zip).
Files that end with “.apk” are the final outcome of Android project, thereby they are ready to be registered in the Android market. The compressed format of this file is zip, which allow us to easily open with compressing programs. However opening this file will not let you decode the meaning since the source files are already compiled.

AndroidManifest.xml

AndroidManifest.xml file is a very important file holding information about the overall structure of the application. Through this file, the Android system finds out component kinds and intent filter and later checks the authority.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml version="1.0" encoding="utf-8"?>
package="com.androidside"
android:versionCode="1"
android:versionName="1.0">
<application android:icon="@drawable/icon"
android:label="@string/app_name">
<activity android:name=".HelloWorld"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
<uses-sdk android:minSdkVersion="9" /> <!-- android 2.3 -->
</manifest>
AndroidManifest.xml can declare the following elements.
<uses-permission /> Authority required by the Application.
<permission /> Authority required by external activity or service.
<instrumentation /> During the occurrence of key events such as activity run, it designates what to call in the application (record, monitoring).
<uses-library /> Designate additional necessary libraries (Google maps).
<uses-sdk /> Android version required for application.
<application /> Application-related information.

Elements and Structure of Android Application

Android has 4 key components:
  • Activity
  • Service
  • Broadcast Receiver
  • And Content Provider
These four components can be closely connected using Intent. Below are the key terms and 4 components for Android. Knowing below words will help you understand better Android.

Android Key Terminology

Component Description
Activity Component for composing UI.
Service Component that runs on the background. No visual UI.
Intent Message element which sends action and data to components.
Intent Filter Defines component by setting intent for receiving.
Broadcast Receiver Receives/responds to a certain broadcast such as lack of battery, language setting/changing. No visual UI.
Content Provider Provides standardized interface for sharing data among applications.
Notification Notifying a certain event to user.
There are various kinds of components for Android, but development using these elements can be described in MVC structure.

VIEW

View is for screen composition and this domain can be composed by using the class which inherits View class provided by Android.

CONTROL

This domain is for connecting and controlling VIEW and MODEL. Activity, Service and BrodacastReceiver are included.

MODEL

This domain is for storing application’s data. SQLite, an embedded database system in Android, File and Content Provider, which can be used for sharing data among applications, are included.

Conclusion

Java SDK is, perhaps, one of the most important advantages of Android which provides various powerful functions of Java programming language. However, many developers complain about Android's fast development pace that they have difficulties to catch up. But if we think more positively, this fast-paced transformation seems to have materialized Android to consolidate itself as the most popular mobile platform. On top of that this popularity has led to many patent suits with Microsoft, thus pressuring many carrier providers to inevitably pay patent fees who initially used the technology thinking it was free. Also Oracle’s patent suit against Google citing that Java cannot be used on mobile devices just because Android uses Java. For above reasons and more, the future path of Android might not seem as smooth as before, but we can’t say it will be gloomy either. I hope all these issues will be settled down, and Android will continue to prosper.
By Dong Ho Han, Web Platform Development Lab, NHN Corporation.

Thursday, 18 September 2014

Set default install location on android device




For some users, rooting is the only way to go. It gives you root access to flash custom ROMs to your device and a number of other cool features. Unfortunately, rooting does void the warranty of your device and the only way to get it back is to restore your phone’s stock software. For those of you who want to try more apps, but aren’t willing to root your phone, there’s an alternative for you. It is possible to install apps on your device’s SD card without rooting your phone.

Requirements

Before you begin, you’ll need to have a few things:
  • You need to move all your applications from your SD card to your phone memory, so that your data will not be lost or corrupted in the process.
  • Download the Java Development Kit (JDK) onto your computer and install it.
  • Download the Android Software Development Kit (SDK) onto your computer and install it.
  • Make sure that your device’s PC Suite has been installed on your computer.
  • Enable USB Debugging on your device through the path “Settings> Applications > Development > USB Debugging”
  • Disable your firewall and antivirus tools on your computer, as they might interrupt the process.

Instructions

Once you’ve got all of these, you may now proceed to installing apps on your SD Card:
  1. After installing both the Java SDK and the Android SDK, run a tool called Android SDK Manager. To do that, you need to open a command prompt, switch to the directory where the Android SDK is installed, and issue the command “android” (without the quotes). Android SDK Manager will start.
  2. In Android SDK Manager, click the “Tools” tab and check whether both “Android SDK Tools” and “Android SDK Platform-tools” are installed. Both need to be installed.
  3. If both items are already installed, close Android SDK Manager.
  4. Connect your device to the computer with the USB Cable.
  5. On the command prompt, switch to the /platform-tools folder inside the folder where the Android SDK is installed.
  6. Issue the “adb devices” command (without the quotes) to check if your phone is properly connected and recognized by your computer. The command will show you the list of attached devices.
  7. If your phone has been properly recognized, issue the command “adb shell pm getInstallLocation” (without the quotes) to see the current install location. It will show one of the following three values:
    • 0 [auto]: Let the phone decide the best location for an app
    • 1 [internal]: It installs everything in the internal storage
    • 2 [external]: It installs everything in the memory card
  8. By default, the install location is set to 0 [auto]. We will need to change the value from 0 to 2, so that the installation happens on your SD card. On the command prompt, issue the command “adb shell pm setInstallLocation 2″ (without the quotes).
  9. If there are no error messages, unplug the phone and restart it. Once it restarts, you’ll be able to easily install applications to your SD card.
Congratulations! You can now install apps to your phone’s SD card even if your phone is not rooted.

Tuesday, 2 September 2014

Secret codesExtraction GT-I9300

NB:THIS INFO WAS SOURCED FROM XDA-DEVELOPERS FORUM


To find all "Secret Codes", special properties and other hidden phone features
and settings, used in the GT-I9300. The secret codes are not so secret, but
are often used to activate and manipulate many settings, such as debug modes,
network connections, factory test modes etc.

It is an unfortunate choice of
words but we will stick to this definition nonetheless for simplicity, since
it is also used in the source code by Samsung and AOS. Do not confuse secret
codes with VSC (Vertical Service Codes), USSD (Unstructured Supplementary
Service Data) or other MMI (Man Machine Interface) codes.

Although there are many "standard" codes common to many Samsung phones, they
do vary to some extent. This is because their functionality often depend on
the particular hardware, in particular the baseband processor (aka radio, DSP,
BP or CP) and the multiplexer chips that switches the various internal USB
paths, for example between MHL, BP and AP.

This is an informative reference thread on these features. If you have
relevant additional information you'd like to share, please post it here.

Background

From the Samsung Galaxy S2 experience we have gained the following
understanding when it come to the Factory/Service Mode menus and the
PhoneUtils applications. We are still to work out if this is still true for
the SGS3.

But first it is worth to note, that due to the more complicated, but better
organized phone applications in ICS, the way to enter secret codes have
changed from GB versions. Now all secret codes have to be prefixed with
"*#*#", followed by <code> and post fixed with "#*#*". [Note-1] However,
according to the GT-I9300 Service Manual, there are two codes that should work
without post- and pre-fixes. They are *#1234# (version) and *2767*3855#
(Factory reset! It will wipe your phone instantly, NO warnings, no going back,
no way to cancel.) [Note-2]
==================================================
Newbie Practice Box
Go to your phone dialer and "dial" the following string:
*#*#197328640#*#*
This will trigger the Service Menu.
==================================================
This same effect can be accomplished directly on the command line, with a
direct URI broadcast call to the application receiver via:

Code:
am broadcast -a android.provider.Telephony.SECRET_CODE -d android_secret_code://1111
Second, it is essential to know that the actual program code (read
assembly/machine code) for the Engineering / Service Mode menu, is actually
located in the baseband processor firmware. What you actually see when you
enter this menu, is just a java based wrapper application, that make direct
function calls through various entry points, in the baseband kernel/firmware.
What does it mean? When you enter a specific "secret code", the wrapper
application (e.g. ServiceMenu.App) deciphers the code to a particular menu
entry in the baseband processor, where it is executed and whose result is
output to the wrapper application.

Third. Apart from hardware differences, because of the baseband firmware
dependance, the set of working secret codes will differ somewhat from your
location, depending on:
  • Your Modem firmware
  • Your AOS version (ICS 4.0.1, 4.0.4 etc.)
  • Your CSC version (Regional codes)

Special Notes

[Note-1] This can be seen in the handleSecretCode() function in the SpecialCh****quenceMgr.java code.
[Note-2] These need testing and confirmation since they clearly contradict [Note-1].
[Note-3] Apparently the Samsung Galaxy S3 will come in at least two versions:
  1. The GT-I9300 (FCC-ID: A3LGTI9300 )
  2. The SCH-I939 (FCC-ID: A3LSCHI939 ) [Possibly the LTE version]


References

So how do you find new codes?
Well Google it! Then consider getting the following tools:
Then what to do?
The brief version. (For full version, see "References" in OP above.)

  1. Download all the tools shown above.
  2. Download the deodexed firmware images (see post#3)
  3. (If in Windows) Double click the sgs2toext4.
  4. Drag and drop the system.img file to the sgs2toext4 "drop window".
  5. You will now have a system.img.ext4 file, open this file with the LinuxReader tool.
  6. Save entire filesystem (from 5) in a new folder. Close.
  7. Go to the folder containing the *.apk(s) of interest.
  8. Make sure dex2jar.bat (win) is in your path and run it on your interesting.apk like this, for example:
    Code:
    ./path/to/dex2jar.bat Samsungservice.apk
    This produces a new file: Samsungservice_dex2jar.jar
  9. Extract (7zip) this file in a new folder.
  10. Go to that folder in command line and enter the appropriate "jad" commands. For example, to decompile all class files globbed by Phone*.class and put the decompiled sources in the "src" sub-directory, do:
    Code:
    jad -o -r -sjava -dsrc Phone*.class
  11. Go to the source directory (../src) you just created.
  12. Enjoy your *.java files!
Alternatively you can deodex on your own...but don't ask me how to do it.

A few other Tools

http://www.sable.mcgill.ca/soot/
http://jdec.sourceforge.net/
http://stackoverflow.com/questions/6...whole-jar-file
http://askubuntu.com/questions/12930...mage-files-img

The information for this post was obtained by decompiling the
deodexed system image of the firmware shown below.

I9300XXALE8

Base Firmware: I9300XXALE8 (4.0.4)
Modem: XXLE8
CSC: OJVALE7


The latest GT-I9300 Stock Firmwares can be found here.

Here are the codes as found in:
serviceModeApp.apk: ServiceModeApp.class

Code:

Code                    Description                                             JavaCall        
----------------------------------------------------------------------------------------------------------------------
197328640 || 2684       Start Service Mode / Enter SM Main Menu                 SendData('\001', '\001', '\000', '\000', '\000');

1111                    FTA SW Version                                          SendData('\001', '\001', '\u1002', '\000', '\000'); 
2222                    FTA HW Version                                          SendData('\001', '\001', '\u1003', '\000', '\000');
8888                                                                            SendData('\001', '\001', '\u1003', '\000', '\000');
2886                                                                            SendData('\001', '\001', ' ',    '\000', '\000');
6984125*                                                                        SendData('\001', '\001', ' ',    '\000', '\000');       
2767*2878               ? Factory reset (complete erase & format)               SendData('\001', '\001', '!',    '\000', '\000');


0228                    ADC Reading                                             SendData('\001', '\001', '\005', '\000', '\000');  
0599                                                                            SendData('\001', '\001', '\024', '\000', '\000');
1575                                                                            SendData('\001', '\001', '\025', '\000', '\000');
2263                    RF Band Selection                                       SendData('\001', '\001', '\026', '\000', '\000');
2580                                                                            SendData('\001', '\001', '\007', '\000', '\000');
301279 || 279301                                                                SendData('\001', '\001', '\024', '\000', '\000');
32489                   Ciphering Info                                          SendData('\001', '\001', '\006', '\000', '\000');
4238378                                                                         SendData('\001', '\001', '\027', '\000', '\000');
4387264636                                                                      SendData('\001', '\001', '\037', '\000', '\000');       
7284                    PhoneUtil: USB/UART I2C Mode Control                    SendData('\001', '\001', '\023', '\000', '\000');
738767633                                                                       SendData('\001', '\001', '\034', '\000', '\000');       
73876766                                                                        SendData('\001', '\001', '\033', '\000', '\000');               
7387677763                                                                      SendData('\001', '\001', '\036', '\000', '\000');
7387678378                                                                      SendData('\001', '\001', '\035', '\000', '\000');       
9090                    Diagnostic Configuration                                SendData('\001', '\001', '\023', '\000', '\000');

0011                                                                            SendData('\001', '\004', '\000', '\000', '\000'); 
123456                                                                          SendData('\001', '\004', '\001', '\000', '\000');
<na>                    End Service Mode 1 ()                                   SendData('\002', '\004', '\000', '\000', '\000');
<na>                    End Service Mode 2 ()                                   SendData('\002', '\001', '\000', '\000', '\000');
NOTE: In the table above, I have replaced printed UTF-8 (U+NNNN) characters with '\uNNNN'.

As you can see in the table above, most of the hidden codes are just shortcuts
into various sub-menus (third parameter) of Service Mode application. However,
this does not exclude the use of other hidden codes, that can be used or detected
in other applications.

From a different file we have a some additional codes.
(Not including already covered or overlapping codes.)

serviceModeApp.apk: SecKeystringBroadcastReceiver.class
Code:
0000                            

147852                  TestApnSettings: putExtra("testBed", "Suwon"); 
1478963                 TestApnSettings: putExtra("testBed", "Open_market");
22558463                Reset Total Call Time
232331                  
232332                  
232337                  
3214789650                      
369852                  TestApnSettings: putExtra("testBed", "Gumi");
3698741                 TestApnSettings: putExtra("testBed", "Delete_DB");
-------------------------------------------------------------------------------
03                      NAND Flash S/N (NandFlashHeaderRead)
745                     RIL Dump Menu
746                     Debug Dump Menu
0228                    Battery Status
1111                    IF SalesCode="CTC" THEN: TerminalMode
2222                    IF SalesCode="CTC" THEN: TerminalMode
2263                    
8888                    
9900 || 0514            System Dump
        
279301                  
301279                  
3214789                 GCF Mode Settings
5337632                 NFC Test
22553767                Call Drop Log View      
                                
6335623                 
TESTMODE                
These may not always work, since some of them depend on certain "Sales Codes"
or factory IMSI numbers, through statements like:
Code:
if ((mSalesCode.equals("CHM")) && (str.equals("827828868378")))
But these were only codes found in two files.
So there are probably many more codes to be found!

Other Stuff

Here are some unknown functions from: TerminalMode.class
Code:
DEBUG_SCR       SendData('\001', '\004', '\000', 0, '\000');
EI_DEBUG_SCR    SendData('\001', '\006', '\000', 0, '\000');
DATA_ADV        SendData('\001', '\003', '\003', 0, '\000');
NAMBASIC        SendData('\001', '\003', '\001', 0, '\000');
TESTMODE        SendData('\001', '\001', '\000', 0, '\000');
NAMSIMPLE       SendData('\001', '\003', '\002', 0, '\000');
TEST_CALL       SendData('\004', '\007', c, 0, '\000');
Here is a list of all the OEM Commands used in the Service Mode App.
Code:
-------------------------------------------------------------------------------
private class OemCommands (ServiceModeApp)      value           hex
-------------------------------------------------------------------------------
char OEM_SERVM_FUNCTAG = '\001';

OEM_SM_ACTION                                   = '\000';       00
OEM_SM_DUMMY                                    = '\000';       00
OEM_SM_END_MODE_MESSAGE                         = '\002';       02
OEM_SM_ENTER_MODE_MESSAGE                       = '\001';       01
OEM_SM_GET_DISPLAY_DATA_MESSAGE                 = '\004';       04
OEM_SM_PROCESS_KEY_MESSAGE                      = '\003';       03
OEM_SM_QUERY                                    = '\001';       01
OEM_SM_TYPE_MONITOR                             = '\004';       04
OEM_SM_TYPE_MONITOR_SKT                         = '\001';       01
OEM_SM_TYPE_NAM_EDIT                            = '\003';       03
OEM_SM_TYPE_PHONE_TEST                          = '\005';       05
OEM_SM_TYPE_SUB_ALL_VERSION_ENTER               = '\004';       04
OEM_SM_TYPE_SUB_BAND_SEL_ENTER                  = '\026';       16
OEM_SM_TYPE_SUB_BATTERY_INFO_ENTER              = '\005';       05
OEM_SM_TYPE_SUB_BLUETOOTH_TEST_ENTER            = '\t';         09
OEM_SM_TYPE_SUB_CIPHERING_PROTECTION_ENTER      = '\006';       06
OEM_SM_TYPE_SUB_ENTER                           = '\000';       00
OEM_SM_TYPE_SUB_FACTORY_PRECONFIG_ENTER         = '\016';       0e
OEM_SM_TYPE_SUB_FACTORY_RESET_ENTER             = '\r';         od
OEM_SM_TYPE_SUB_FACTORY_VF_TEST_ENTER           = '\031';       19
OEM_SM_TYPE_SUB_FTA_HW_VERSION_ENTER            = '\003';       03
OEM_SM_TYPE_SUB_FTA_SW_VERSION_ENTER            = '\002';       02
OEM_SM_TYPE_SUB_GCF_TESTMODE_ENTER              = '\027';       17
OEM_SM_TYPE_SUB_GET_SELLOUT_SMS_INFO_ENTER      = '\037';       1f
OEM_SM_TYPE_SUB_GPSONE_SS_TEST_ENTER            = '\025';       15
OEM_SM_TYPE_SUB_GSM_FACTORY_AUDIO_LB_ENTER      = '\030';       18
OEM_SM_TYPE_SUB_IMEI_READ_ENTER                 = '\b';         08
OEM_SM_TYPE_SUB_INTEGRITY_PROTECTION_ENTER      = '\007';       07
OEM_SM_TYPE_SUB_MELODY_TEST_ENTER               = '\013';       0b
OEM_SM_TYPE_SUB_MP3_TEST_ENTER                  = '\f';         oc
OEM_SM_TYPE_SUB_RRC_VERSION_ENTER               = '\024';       14
OEM_SM_TYPE_SUB_RSC_FILE_VERSION_ENTER          = '\021';       11
OEM_SM_TYPE_SUB_SELLOUT_SMS_DISABLE_ENTER       = '\034';       1c
OEM_SM_TYPE_SUB_SELLOUT_SMS_ENABLE_ENTER        = '\033';       1b
OEM_SM_TYPE_SUB_SELLOUT_SMS_PRODUCT_MODE_ON     = '\036';       1e
OEM_SM_TYPE_SUB_SELLOUT_SMS_TEST_MODE_ON        = '\035';       1d
OEM_SM_TYPE_SUB_SW_VERSION_ENTER                = '\001';       01
OEM_SM_TYPE_SUB_TFS4_EXPLORE_ENTER              = '\017';       0f
OEM_SM_TYPE_SUB_TOTAL_CALL_TIME_INFO_ENTER      = '\032';       1a
OEM_SM_TYPE_SUB_TST_AUTO_ANSWER_ENTER           = ' ';          20
OEM_SM_TYPE_SUB_TST_FTA_HW_VERSION_ENTER        = ---->         # UTF-8: U+1003: e1 80 83  MYANMAR LETTER GHA
OEM_SM_TYPE_SUB_TST_FTA_SW_VERSION_ENTER        = ---->         # UTF-8: U+1002: e1 80 82  MYANMAR LETTER GA
OEM_SM_TYPE_SUB_TST_NV_RESET_ENTER              = '!';          21
OEM_SM_TYPE_SUB_USB_DRIVER_ENTER                = '\022';       12
OEM_SM_TYPE_SUB_USB_UART_DIAG_CONTROL_ENTER     = '\023';       13
OEM_SM_TYPE_SUB_VIBRATOR_TEST_ENTER             = '\n';         0a
OEM_SM_TYPE_TEST_AUTO                           = '\002';       02
OEM_SM_TYPE_TEST_MANUAL                         = '\001';       01

-------------------------------------------------------------------------------
private class OemCommands (TerminalMode)
-------------------------------------------------------------------------------
OEM_HIDDEN_FUNCTAG                              = 'Q';
OEM_HM_END_TEST_CALL_MESSAGE                    = '\t';
OEM_HM_TEST_CALL_MESSAGE                        = '\004';
OEM_HM_TYPE_TEST_CALL                           = '\007';
OEM_SERVM_FUNCTAG                               = '\001';

-------------------------------------------------------------------------------
private class OemCommands (SysDump:)
-------------------------------------------------------------------------------
OEM_DBG_STATE_GET =             6;
OEM_DEL_RIL_LOG =               13;
OEM_DPRAM_DUMP =                14;
OEM_DUMPSTATE =                 3;
OEM_DUMPSTATE_ALL =             20;
OEM_ENABLE_LOG =                7;
OEM_GCF_MODE_GET =              15;
OEM_GCF_MODE_SET =              16;
OEM_IPC_DUMP_BIN =              9;
OEM_IPC_DUMP_LOG =              8;
OEM_KERNEL_LOG =                4;
OEM_LOGCAT_CLEAR =              5;
OEM_LOGCAT_MAIN =               1;
OEM_LOGCAT_RADIO =              2;
OEM_MODEM_FORCE_CRASH_EXIT =    23;
OEM_MODEM_LOG =                 18;
OEM_NV_DATA_BACKUP =            17;
OEM_OEM_DUMPSTATE_MODEM_LOG_AUTO_START = 19;
OEM_RAMDUMP_MODE =              10;
OEM_RAMDUMP_STATE_GET =         11;
OEM_START_RIL_LOG =             12;
OEM_SYSDUMP_FUNCTAG =           7;
OEM_TCPDUMP_START =             21;
OEM_TCPDUMP_STOP =              22;
-------------------------------------------------------------------------------
Enjoy!
Next we'll have a look at some interesting (or not?) system "properties".
For now, I'll just list some of those I found more interesting and potentially useful.


Code:
Property                Setting/String                  Source                                  Description
----------------------------------------------------------------------------------------------------------------------
dev.silentlog.on        On                              SysDump:                                
gsm.operator.numeric    45001                           Sec_Ril_Dump:                   [RIL::FD] Samsung Testbed
gsm.default.sidmode                                                                     ? UART
net.tcpdumping          On                              SysDump:                        ?
nfc.trace.mode          On                                                              Enable NFC Trace Mode 

ril.FTM_MODE                                                                            ? "FTM_MODE_KEY"
ril.FS                  true                            PhoneUtils: updateRAFT()        Activates RAFT (???) updates
ril.OTPAuth                                             SysDump:                        OTP Authentication 
ril.cdma.inecmmode      true                                                            Is phone in ECM mode?
ril.unique_number                                                                       The RIL Unique Number (UN)
ril.sms.gcf-mode        On                                                              ? SMS "GCF" mode

persist.log.seclevel    On                                                              Switchable Log level?
persist.sys.country                                                                             
ro.build.type           eng                             SysDump:                                
ro.debuggable           On                                                              Enable Debug / DBG_ENG / Engineering Mode??
----------------------------------------------------------------------------------------------------------------------
Country/Region Specific
----------------------------------------------------------------------------------------------------------------------
ro.board.platform                                       
ro.build.characteristics                                
ro.csc.sales_code       SKT | KIT | LGT                 PhoneFeature: makeFeatureForKor()       
ro.product.name         espressorf | espresso10rf       PhoneFeature: checkDBGLevel()           
                        aegis2vzw                       PhoneFeature: makeFeatureForKor()       
                        jaguars | jaguark | jaguarl     
A particularly fun string is the following, found in the featureForKor() function:
Code:
mFeatureList.put("emergency_for_cyber_terror", boolean2);
I'd really like to know what this does!

Special Files

As we know from other Samsung Galaxy class phones, there are a number
of files that can be created or modified in order to activate certain
functions. Here we list those found to date. Please post if you know
of other ones!

Apparently setting the "SubscriberID" (IMSI) to "999999999999999" also
activates certain test features. A sim with this IMSI is also known as
a "Factory SIM". However, if the SIM IMSI starts with either "45001" or
"00101" it is a "Test SIM".

[See: ServiceModeApp.apk:PhoneUtils.java:isFactoryMode() or
FactoryTest.apk:ModuleCommon.java:isFactorySim()]

Code:
File                            FileContent     Description
-------------------------------------------------------------------------------
/efs/FactoryApp/factorymode     ON              Enable Factory Mode
/efs/FactoryApp/keystr          ON              Blocked (hidden code?) Key String(s)
/efs/imei/mps_code.dat          ?               ?
/efs/root/ERR                   ?               Error Log
/data/.psm.info                 ?               WiFi Power Save Mode    

---------------------------------------
Various Log Files:
---------------------------------------
/data/log/CallDropInfoLog.txt   ?               Dropped Calls Log
/data/log/lucky_ril.log         ?               ?
/data/log/dumpState_*.log       ?               ? System Dump Log
/data/log/main_*.log            ?               ? 
/data/anr/traces.txt            ?               ? 
/data/log/err                   ?               ? Error Log
/data/log/err/AENEAS_TRACE_###.bin              RF Aeneas Trace Log
/data/log/err/MA_TRACE_###.bin                  RF MA Trace Log
/mnt/sdcard/log                 ?               ?

---------------------------------------
System Files 
---------------------------------------
/sys/class/sec/switch/adc                       
(Note: Some of these paths need to be verified, as they may be relative...)

Finally, we have two NVpasswords, that is used for uploading or dumping NVram, AFAIK. They are:
873283
3352225
and they can be found in Sec_Ril_Dump.class.

DISCALIMER:

As I do not have access to a GT-I9300, I have not been able to verify
any of the information in this thread! I apologize if there is any erroneous
information here. Please let me know and post new information here as
it become available. Also make sure you make a complete backup, before
attempting any of the codes or other trickery above
!


Reprogramming smartcards (SIM CARDS)


 Here is the link for the time being ...

http://www.jaycar.com.au/productView.asp?ID=KC5361

I remember when Dejan found the binary hack way back in 2006 for BB5 Nokia phones, he posted files on his website on how to clone a simcard. But those times only 16bit chips were used.

Here is the scheme tics for the reader if any one interested.
Tricks and Tips