Monthly Archives: October 2013

Unpack/repack ext4 Android system images

http://andwise.net/?p=403

 

This is for all who want to unpack and modify the original system.img that you can flash using recovery.

system.img (what you get from the google factory images for example) represents a sparsed ext4 loop mounted file system.

It is mounted into /system of your device. Note that this tutorial is for ext4 file system, you may have system image which is yaffs2 for example.

the way it is mounted on Galaxy Nexus:

“/dev/block/platform/omap/omap_hsmmc.0/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0″

Prerequisites:

  1.  Linux box or virtual machine
  2. simg2img, make_ext4fs binaries which can be downloaded from here http://web.djodjo.org/?a=download:android:tools:x86_linux:ext4tools

Procedure:

place you system.img and the 2 binaries in one directory, and make sure the binaries have exec permission.

Part 1 – mount the filesystem

  1. mkdir sys
  2. ./simg2img system.img sys.raw
  3. sudo mount -t ext4 -o loop sys.raw sys/

Then you have all your system partition mouned in ‘sys’ and you can modify whatever you want in ‘sys’. For example de-odex apks and framework jars.

Part 2 – create a new flashable system image.

  1.  sudo ./make_ext4fs -s -l 512M -a system new.img sys/
  2. sudo umount sys
  3.  rm -fr sys

Now you can simply type:

fastboot flash system new.img

Advertisements

protection level, Android permission

http://developer.android.com/reference/android/R.styleable.html#AndroidManifestActivity_permission

 

Constant Value Description
normal 0 A lower-risk permission that gives an application access to isolated application-level features, with minimal risk to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application at installation, without asking for the user’s explicit approval (though the user always has the option to review these permissions before installing).
dangerous 1 A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Because this type of permission introduces potential risk, the system may not automatically grant it to the requesting application. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities.
signature 2 A permission that the system is to grant only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user’s explicit approval.
signatureOrSystem 3 A permission that the system is to grant only to packages in the Android system image or that are signed with the same certificates. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. This permission is used for certain special situations where multiple vendors have applications built in to a system image which need to share specific features explicitly because they are being built together.
system 0x10 Additional flag from base permission type: this permission can also be granted to any applications installed on the system image. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. This permission flag is used for certain special situations where multiple vendors have applications built in to a system image which need to share specific features explicitly because they are being built together.
development 0x20 Additional flag from base permission type: this permission can also (optionally) be granted to development applications.