Help talk:Starting a new page

History
Android, Inc. was founded by two people, Andy Rubin (co-founder of Danger), and Rich Miner (co-founder of Wildfire Communication, Inc.) Nick Sears (once VP at T-Mobile), and Chris White (headed design and interface development at WebTV) to develop, in Rubin's statement, "smarter mobile devices that are more aware of its owner's location and preferences" in Palo Alto, California in October 2013. First intentions of this development is only to develop a Mobile Operation System that use for Digital Camera. After that they was thinking that the market of mobile operation system is large enough for them to develop an operation system for smartphone in order to compete to the existing system such as Symbian and Microsoft. In the same year, Rubin run out of money. Then his close friend, Steve Perlman brought him $10,000 to setup the company, but he refused to be a stockholder in this company.

As seen the huge amount of using android operation system in many smartphone device. In July 2005, Google, Inc. acquired Android Inc. for at least $50 million, and hired key employees such as Rubin, Miner and White to stay at the company after the acquisition. The team which leaded by Rubin have developed a mobile device platform powered by the Linux Kernel. Google want to a mobile platform market to handset makers and carriers on the promise of providing a flexible, and upgradable system. Google had lined up a series of hardware component and software partners and signaled to carriers that it was open to various degrees of cooperation on their part. In December 2006, google has released a first prototype device which has the codename “Sooner” that the device appearance is look similar to a BlackBerry phone, with no touchscreen, and a QWERTY Keyboard, but was re-engineered to have ability to support a touchscreen, to compete with another devices such as the 2006 LG Prada and 2007 Apple iphone.

On November 5, 2007, the Open Handset Alliance, a consortium of technology companies include Google, HTC, Sony and Samsung, Qualcomm and Texas Instruments ,Sprint Nextel, T-Mobile, have an agreement on how to develop an open standards for mobile devices. At that moment Android mobile device platform built on the Linux Kernel version 2.6.25. The first smartphone running Android was the HTC Dream which released on October 22, 2008. In 2010, Google released its Nexus devices smartphone and tablets running the Android operation system, and built by manufacturing partners. The Nexus One was cooperated with HTC. Then the new series such as Nexus 5 made by LG and the Nexus 7 tablet made by Asus. At that time only the Google Nexus phone and tablet devices that enable to install the latest software and hardware features. Until 2015, Google provided several Google Play Edition, as Google customized Android phones and tablets.

On March 13, 2013, Larry Page announced that Andy Rubin had moved from the Android to take on new projects at Google. Sundar Pichai head of Google’s Chrome division come to replace Rubin.

Since 2008, Android version frequently update its version to improve the operating system, with new features added and fixing the error bugs. Each major release is named in alphabetical order after a dessert or sugary. For instance, version 1.5 “Cupcake”, follow by 1.6 “Donut”. In 2014, Google launched Android One, a standardized smartphone. Android One smartphones running the latest version of Android. March 3, 2015, the newest version of the Android operating system, 5.1 (lollipop), is available for selected devices including the Android One series such as Nexus 6 phablet, Nexus 9 tablet.

In May 2015, Google was announced the Project Brillo as a cut-down version of Android that uses its lower levels (excluding the user interface), intended for the "Internet of Things" (IoT) embedded systems.

Android Evolution
As early mention above in History from 2008 the version of Android operating system seem numerous updates which have incrementally improved the operation system. Each release version is named in alphabetical order after a dessert or sugary treat.

Alpha (1.1)
In 2007, Google has released two internal version known as Alpha and Beta version. For this internal releases, names of fiction robots were chosen, with various code-named “Astro Boy”, “Bender”, and “R2-D2”. The first mascot logos was created by Dan Morrill, but the current green Android logo was designed by Irina Blok. The project manager, Ryan Gibson, conceived the confectionary-themed naming scheme that has been used for the majority of the public releases, starting with Android 1.5 "Cupcake".

Beta (1.2)
The beta was released on November 5, 2007, while the software development kit (SDK) was released on November 12, 2007. The November 5 date is popularly celebrated as Android's "birthday". Public beta versions of the SDK were released in the following order:
 * November 12, 2007: m3-rc20a (milestone 3, release code 20a)
 * November 16, 2007: m3-rc22a (milestone 3, release code 22a)
 * December 14, 2007: m3-rc37a (milestone 3, release code 37a)
 * February 13, 2008: m5-rc14 (milestone 5, release code 14)
 * March 3, 2008: m5-rc15 (milestone 5, release code 15)
 * August 18, 2008: 0.9
 * September 23, 2008: 1.0-r1
 * Beta (version 1.2)

Cupcake (1.5)
After the first major internal release, Android releases the second major called “Cupcake”. With this version Android come along with the first touchscreen phone which known as HTC Magic phone. Cupcake come along with the following feature:
 * Introduced Widget feature that allowing third parties to produce widgets for Android.
 * Enable the copy-and paste feature- from plain text on a page to internal apps.
 * Improvement of the camera, during taking a photo user can also switch to video mode
 * Improve in GPS (Global Position System) position speed detection
 * Record video both in MP4 and 3GP file formats.
 * Offer auto screen rotate.
 * Virtual Keyboard
 * Automatic loading of videos stream on YouTube, and Picasa.

Donut (1.6)
This version was launched in September 2009, was also known as Donut. In this new feature Android has added some new features:


 * Text-to-speech technology
 * Search can be done by using both text and voice; and this is not restricted to just the web; we can search bookmark history, contacts, music, dictionary and web with this method and from the same search box.
 * There is not screenshot available in this version
 * New update allow for WVGA Screen Resolutions and better performance
 * Integrate the camera and gallery apps, for better and faster viewing of photos taken from the camera.

Éclair (2.0.x & 2.1)
In October 2009, Android 2.0 and its updatable 2.1 called Éclair was released and bring in a revamped user interface experience (UI) and the introduction of Live Wallpapers (animated wallpapers at the home screen). Another features such as virtual keyboard for a faster typing experience and if typing take too long, then the speech-to-text technology is the best alternative. With this version also come along with Bluetooth 2.1 support for faster file transfer.

For one user who has multiple email could browse their multiple accounts at the same time and account sync enables synchronization of email and contacts easily. To make a phone call or send message just simply long press on the wanted contact, then select to call or send message. Moreover, the camera app offers flash shooting, and many option for image quality such as white balance, contrast. To make an easy way read the text on the web browser by double tap to make a zoom in. This version can support for HTML5 and an improved navigational experience with Google Map.

Frozen Yogurt "Froyo" ( 2.2.x)
Released on May 2010, it propose the completion away in terms of operating system speed by getting the advantage of Java V8 and JIT (Just-In-Time) compiler engine which boost up app speed faster than ever. In addition to this operating system improvement, this version has improve and added some feature as below:


 * USB tethering and portable Wi-Fi hotspot (sharing a connection via WIFI)
 * User can enable or disable data access
 * Enable to run Adobe Flask 10.1 on android device and picture preview in the 3D photo gallery.
 * Embedded with Multilingual Keyboard
 * Remote wipe that allow to wipe out data when phone was lost or stolen, this feature for a better data protection

Ginger Bread (2.3.x)
Six month later after Froyo announced, Android 2.3 came to light at the end of year. This version came along with the following feature:


 * UI(User Interface) was revised for easier and faster use experience
 * Enable to switch between the font and real camera for dual camera phone
 * Copy-paste feature can be done word by word
 * Provide a better battery management tools that allow user to see which app is zapping battery juice the most
 * Integrated Internet calls
 * Version 2.3.7 was introduced Google Wallet which utilizes near field communication to store cards, redeem promotions and even make secure payment from your phone.

Honeycomb (3.x.x)
Android 3.0, Honeycomb was released to use for a wide screen device which known as tablet. The main improvement of this version is focusing on UI. There are no physical buttons such as back, select, and home etc. Widgets become more visibility to the user as large screen of tablet. There are two main bars in the main view, at the top the action bar, which gives access to individual app and widgets, at the bottom, the system bar showing notifications and soft navigation buttons.

As wide screen device, it will allow for a better keyboard typing with more accurate. Can have multiple tabs on a single browser. This version also has improved for a better hardware acceleration and 3D graphics support. For the later updates the connectivity of USB accessories such as external keyboards or gamepads. Offer an easy way to transfer of media files to your PC.

Ice Cream Sandwich (4.0.x)
First released on October 2011 and updated in March 2012, it provide an unmatched performance and speed, consists of many features that Honeycomb installed in the tablets over to smartphone. User can add their favorite apps and widgets to the home screens or panels through drag-and-drop.

Enable to use video chat in GTalk, which also carries Face Lock. In this version of android, user can make a screenshots of the current screen. Provide a better appearance and performance of Google Chrome for android. Usage can be broken down by time spent for a better battery management and user can also receive warnings when over data limit, or disable data usage once. It also has a snapshot capture feature which is initialed by pressing both the power and the volume-down button together. To have a better and fast typing a text prediction technique was added. Other improvements was added to voice input, copy-and-paste, social network feature, camera can take a photo with a panorama view and option to share to social profile.

Jelly Bean (4.1.x, 4.2.x & 4.3.x)
In June 2012, by smeared with butter, a project was called Project Butter made this latest update, faster, smoother, and more responsive. This version consists a lot of feature as below:


 * Animation and transition are also visibly enhanced with vsync timing.
 * Notification received can easily expand with finger gestures to get the full info without launching the app
 * Voice search is implemented in Google Now (so just simply said something you will get some result back), as Voice dictation is now an offline, integrated feature.

KitKat(4.4.x)

 * Support for Bluetooth MAP
 * New framework for transitions in the user interface
 * Support for wireless printing
 * Optimization of memory and touch screen for faster multitasking

Lollipop(5.x.x)
The latest version of Android which released on 15 October 2015 by Google alongside of the Nexus 6. This version brings a huge UI (User Interface) makeover which closely follows material design. Oppose to KitKat, the design changes have been evenly distributed throughout the phone’s system.

In addition to a brand new look, Lollipop includes many new and exciting features, like Tap & Go (easy data transfer to your new phone via NFC), floating notifications, built-in battery saver, encryption, multiple user profiles and a smarter Google Now. Of course, Google also included a new Easter Egg which pays homage to one of the year’s most popular games, Flappy Bird. Instead of the bird, you must control the little Android robot along a landscape of multi-colored lollipops! Android Lollipop is definitely much more vibrant, colorful and flat than any other Android version. Android 5.0 Lollipop review


 * Device sharing: multiple users and profiles on smartphones
 * Material Design
 * Battery Saver
 * Android Smart Lock
 * ART instead of Dalvik runtime

Architecture
The hardware architecture of the android mobile technology is based on the ARM (Advanced Risc Machine) Cortex –A8 processor. ARM® Cortex™-A8 microprocessor is the first applications microprocessor in ARM’s new Cortex family with high performance and power efficiency, targeting a variety of mobile and consumer device applications. The Cortex-A8 processor provides a range of performance points depending on the implementation by delivering over 2000 Dhrystone MIPS (DMIPS) of performance for demanding consumer applications and consuming less than 300mW for low-power mobile devices. This large increase in processing capability while keeping the device power level low will benefit with reduced heat dissipation, resulting in low power packing and integration costs.

This Cortex –A8 processor incorporates all of the new technologies available in ARMV7 architecture. Additionally for the first time it included the NEON™ for media processing and signal processing and Jazelle® RCT for acceleration of real-time compilers. Other technologies incorporated in these processor are TrustZone® technology for security, Thumb®-2 technology for code density and VFPv3 floating point architecture.



Figure 1:Android OS Hardware Architecture

Overview of the Cortex-A8 Architecture
Thumb-2 technology: Thumb -2 technology is the Unifying technology of cortex processers. The original arm instruction set consists of fixed length 32 bit instructions while the thumb instruction set employs 16 bit instructions. Thus the Thumb-2 instruction set combines 16- and 32-bit instructions to improve code density and performance. Additionally the Thumb2 technology adds about 130 instructions to the thumb, this added functionality removes the need to switch between arm and thumb modes in order to service interrupts, and give access to the full set of processor registers.

NEON media and signal processing technology: Initially Neon in the arm processor is targeted for audio, video and 3D graphics. It is a 64/128 hybrid SIMD (single instruction multiple data) architecture. Neon technology has its own register file and execution pipeline which are separate and from that of the arm processor. It can handle both integer and single precision floating point values and includes support for unaligned data accesses and easy loading of interleaved data stored in structure form. Using this neon technology the Cortex-A8 processor can decode MPEG-4 VGA videos.

Jazelle RCT technology: this is an architecture extension that cuts the memory footprint of just-in-time (JIT) byte code applications to a third of their original size. The smaller code size results in a boost performance and a reduction or power.

TrustZone technology: This technology is included in the cortex-A8 to ensure data privacy and DRM protection in consumer products like mobile phones, personal digital assistants and set-top boxes that run open operating systems. Additionally being implemented within the processor core, TrustZone technology protects peripherals and memory against a security attack.

The VFPv3 technology: This technology provides conversions between 16-bit, 32-bit and 64-bit floating-point formats and ARM integer word formats, with special operations to perform conversions in round-towards-zero mode for high-level language support.

Dear readers since our study focuses on the android security we mentioned the above hardware architecture to show the hardware security protection in the TrustZone technology at hardware level in the cortext-A8 processor. The detail explanation about the hardware internal structure, L1 cache, L2 cache, pipeline and the memory structure can be found here in the arm processor manufacturer website. Next we will try to explain the Android software architecture which is abstracted up on the arm coretex-a8 and different accessories.

Android OS Software Architecture
The Android Operating system is a software stack consisting of the following layers. The Kernel and low level tools, native libraries, the android runtime environment, the framework layer and on top of all the applications.



Figure 2:Android Anatomy. Green items are written in C/C++, blue items are written in Java and run in the Dalvik VM.

The Linux Kernel
Positioned at the bottom of the Android software stack, the Linux Kernel provides a level of abstraction between the device hardware and the upper layers of the Android software stack. Based on Linux version 2.6, the kernel provides preemptive multitasking, low-level core system services such as memory management, process management and power management in addition to providing a network stack and device drivers for hardware such as the device display, Wi-Fi and audio.

Android runtime –Dalvik Virtual Machine
The Linux kernel provides a multitasking execution environment allowing multiple processes to execute concurrently. If so it would be easy to assume, that each Android application simply runs as a process directly on the Linux kernel. In fact, each application running on an Android device does so within its own instance of the Dalvik virtual machine (VM).

Running applications in virtual machines provides a number of advantages.
 * Firstly, applications are essentially sandboxed (we will discuss these in detail later on ), in that processes  cannot detrimentally interfered (intentionally or otherwise) with the operating system or other applications, nor can they directly access the device hardware.
 * Secondly, running the application in separate virtual machine enforces level of abstraction that makes applications platform neutral in that they are never tied to any specific hardware.

The dalvik virtual machine is developed by Google for low level functionality of Linux kernel. These is more efficient than the normal java virtual machine in terms of memory usage, and specifically to make multiple instances run at the same with the given limited resources of mobile app.

Application Structure

To execute the code with in the dalvik virtual machine codes should be changed from standard java class to dalvik executable (.dex) format. This executable byte code has 50% smaller memory footprint than the normal java byte code. Java code has extension .java which will be compile to .class file in JVM (Java Virtual Machine). The JVM loads the byte code for a Java class from the associated .class file as it referenced at run time. Furthermore, a Dalvik application consists of a single .dex file containing all application classes. Sees figure 3 below Java source codes are compile to JVM bytecode, then the Dalvik dx compile will consumes the .class files, DVM will recompile them to Dalvik bytecode. Finally, DVM writes the result into a single .dex file.



Figure 3:Compilation process from Java source code to a single .dex file in DVM

The overall process for this mechanism consists of the translation, re-construction, and interpretation of the basic three block elements of the application.
 * Constant pool: A constant pool used to describe the constants used by an individual class. It contains items, method names, numerical constants, and reference to other classes.
 * Class definition: The class definition include the basic information such as access flag and class names.
 * Data segment: The data element contains the method code executed by the target VM (Virtual Machine), as well as other information related to methods (i.e. number of DVM registers in used, local variable, and operand stack size) and to class and instance variable.

Register Structure

The JVMs are stack-based while DVM is register-based. Java bytecode all local variables are assigned to a local variable table ahead before pushing them to an operand stack for manipulation by opcodes. The Dalvik bytecode all local variables are assigned to any of 216  available registers. Then the Dalvik opcodes directly manipulate register rather than accessing elements on a program stack.

Instruction set

The Dalvik has 218 opcodes while Java only has 200 opcodes. Dalvik instructions set intended to be wider than Java instructions. They are included the source and destination registers. In Dalvik applications have 30% fewer instructions than Java, but have a 35% larger code size (bytes). Hence, Dalvik applications require fewer instruction.

Android runtime-core libraries
These android core libraries fall in to three categories.


 * a) Dalvik virtual machine Specific libraries : these are libraries used to directly interact with the instance of dalvik virtual machine


 * b) Java interoperability libraries: android is developed using java programing language where there is a lot arrays of java classes in the core java runtime libraries. Java interoperability libraries are open source implementation that have adapted for use with the dalvik virtual machine


 * c) Android libraries: these are libraries specific for java android development.

C/C++ libraries
C and C++ libraries are included for the purpose of the 2D and 3D graphics drawing, Secure Sockets Layer (SSL) communication, SQLite database management, audio and video playback, bitmap and vector font rendering, display subsystem and graphic layer management and an implementation of the standard C system library (libc) and the like. For example when we make a call to android openGl to draw a 3D graphics the library in turn calls the openGl ES C++ library which in turn rely on the underlying Linux kernel.

Application Framework
These are a set of services that collectively prepare the environment in which the android application run and managed. The Framework implements the concept that android applications are constructed from reusable, interchangeable and replaceable components. The following key services are provided by the android framework
 * Activity manager: used to control all aspects of application life cycle and activity stack.
 * Content provider: these allows the application to publish and share data with other applications
 * Resource Manager: gives access to non-code embedded resources such as strings, color setting and user interface layouts.
 * Notification Manager: Allows application to show alerts as well as notification messages to the user.
 * View System: An extensive set of views used to create application user interfaces
 * Package Manager: this is a system by which application finds out information about another application currently installed on the device
 * Telephony Manager: gives information about telephony service on the device such as status and subscriber information
 * Location Manager: provides access about to location service allowing devices to get update about the location changes

Applications
Applications are located at the top of the android software stack. These are the combination of native applications as well as third party applications installed on the android device.

kernel security
As it has been explained in the introductory part the foundation of android platform is the Linux kernel. One of the main reason why Linux was chosen as the android platform is its provision for great security permission model. The Linux kernel itself has been a widespread use for years, and is used in millions of security-sensitive environment. As the base for mobile environment the Linux kernel provides Android with several key security features including
 * A user based permission model
 * Process Isolation
 * Extensive mechanism for secure IPC
 * The ability to remove unnecessary and potentially insecure parts of the kernel

As a multiuser operating system, the fundamental security objective of the Linux kernel for the android system was to isolate resources from one another. These security philosophy of the of the Linux is to protect user resources from one another. Thus Linux:-
 * Prevent user A from reading user B’s files
 * Ensure that user A does exhaust user B’s memory
 * Ensure that user does not exhaust user B’s CPU resources
 * Ensure that user A does not exhaust user B’s devices

In android applications and services run in a separate processes which is called the application sandbox. When different processes want to share data or when one application want to get data from one process of service they use binder or IPC. Let us explain application sand box and binder one by one.

Application Sandbox
Android platform takes advantage of the Linux-based protection as a means of identifying and isolating application resources. The system assigns a unique user ID (UID) to each android application and run as that user is a separate process. Each process runs on its own Dalvik virtual machine (DVM).



Figure 4: Android Security Sandbox

The above figure shows that App1 and App2 in androids kernel-level application are sandboxed. With these the kernel enforces security between applications and the system at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. By default, applications cannot interact with each other and applications have limited access to the operating system. If application App1 tries to do something malicious like read application App2's data or dial the phone without permission (which is a separate application ), then the operating system protects against the action because application A does not have the appropriate user privileges to access application App2 in other words each process are sandboxed. The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions.



Figure 5: Without App Sandbox vs. with App Sandbox

Since the application sandbox is in the kernel, this security model extends to native code and to operating system applications. All of the software above the kernel including operating system libraries, application framework, application runtime, and all application run within the application sandbox. On android there are no restriction on how an application can be written that are required to enforce security.

In some operating systems, memory corruption errors generally lead to completely compromising the security of the mobile device. This is not the case in Android due to all applications and their resources being sandboxed at the OS level. A memory corruption error will only allow arbitrary code execution in the context of that particular application, with the permissions established by the operating system.

Security in Binder (IPC)
Even if applications and services can run independentlly they must communicate and share data between each other. In android these is implemented using the binder (inter process communication driver). IPC can introduce significant processing overhead and securiy holes. These can be explained in the following diagram.



Figure 6: Inter process communication in Binder driver

These diagram expains interprocess communication between client and server process via the binder driver.
 * 1) The Binder framework calls an ioctl syscall with the file descriptor of /dev/binder as a parameter and transfers the relevant data to the kernel.
 * 2) The driver then looks up the required service, copies the data to the system server's address space, then wakes up a waiting thread in the server process to handle the request
 * 3) The server performs the requested service( if the object has relevant permission example like make network connection), and if necessary calls into the kernel to interact with the relevant hardware
 * 4) Server receives response from the hardware
 * 5) The copy of libbinder which is loaded within the server's own address space marshals the response data and sends it back to the driver
 * 6) Finally the binder hands it back to the client process

Since these information highway going into and out of an app will coontain massive amounts of data-an attacker who can tap into this data will immeidiately gain immense power over the device. Furthermore, controlling the information to Binder is a uniquely portable way to steal and modify user data in Android. An attacker does not need to know anything about the implementation of a sp ecic app: regardless of the application's internal complexity, it will eventually have to call a limited set of system services.

So at Binder or at interprocess commucinication level the security of android application has limitations and there are holes to malware and attackers.

Application security
Android is an open source platform and application environment for mobile devices. As it is an open source platform, android provides the SDK (Software Development Kit) for developer to create Android application. The Android SDK enable developer to build Android applications by using Javvav programming language and run in the Dalvik virtual machine. Developers can also written Android application with a native code (C/C++ programming language) by using Android NDK (Native Development Kit). Every source packages are put into one installable file with extension .apk.

Figure 7 below illustrated the android security related use-case in the android application development process.


 * Application or code signing is the process of generating private and public keys and public key certificates, optimizing application and signing the application. The signing allows developers to identify the author of the application and to update their application without creating complicated interfaces and permissions. All Android application must be signed by the developer. Unless, the application that attempt to install without being signed will rejected by either Google Play or the package installer on the Android device.
 * Permission are an Android platform security mechanism to allow or restrict application access to restricted APIs and resources. By default, Android application have no permissions granted, in order to make them safe by not allowing them to gain access to protected APIs or resources on the device. Permission must be requested, customized permissions defined in the manifest (AndroidManfest.xml file), and file and content providers protected. All enforcements, grants, and revoke permission are checked at runtime.



Figure 7: Android application security in development phase.

Application signing
On Android application development, application or code signing is the first step to placing an application in its Application Sandbox (more detail information about application sandbox see section 5.1.2). The signed application certificate defines which user id is associated with which application. Application signing ensures that one application cannot access any other application except through well-defined IPC.

Every Android application have to sign before make it available in the Android market. Application or code signing is the process of digitally signing a given application using a private key to:
 * Identify the code’s author
 * Detect if the application has changed
 * Establish trust between applications

Application signed using the same digital signature can grant each other permissions to access signature-based APIs and also can run in the same process if they share users IDs, allowing access to each other’s code and data. Application signing begins by generating a public and private key pair and a related public-key certificate, this key pair know as public-key certificate.

Android application developments are divided into two main phase; debug and release-mode.
 * Application built using the Android build tools such as command line or Eclipse ADT are automatically signed by using a debug private key. The debug mode applications are used for testing and could not be shared distributed. Both signed and unsigned application which using a debug private key cannot be distributed via the Android Market.
 * After debugging the application and completely test, the application are ready to release. To build a release mode version of it, which means signing the application with your private key.

Application or code singing in Android is done in a much simpler than other mobile platform. The certificate is a self-signed that don’t need a certificate authority. This will easy way to publish the application and related cost.

Next, I will cover on how to sign Android application manually from the command line and Eclipse ADT. To generate the private and public key manually using the keytool from the command line. The command line below use to generate private/public keys and certificate.


 * Keytool –genkey –v –alias  -keystore  -keyalg RSA –keysize 2048 -validity

Note:


 * genkey: indicates a public and private key pair entry, as well as an X.509 v1 self-signed, single-element certificate chain that includes the generated public key.
 * v: indicates verbose-mode.
 * alias : is the alias to use for the keystore entry that stores the generated private key and certificate
 * keystore: indicates the name of the keystore to use.
 * Keyalg: is the algorithm to use to generate the key pair.
 * Keysize: is the size of the key to generate where the default is 1024 but 2048 is recommended.
 * Validity: is the validity period in days; a value greater than 1000 is recommended.

Keytool prompts for your first and last names, organization, city, state, country from which a X.500 Distinguished Name is generated, and passwords to protect the private key and to protect the keystore itself

Next, sign the unsigned application using the jarsigner tool, which is part of the JDK:


 * jarsigner -verbose -keystore   

Note:
 * Verbose: indicates verbose mode, and
 * Keystore: indicates the name of the keystore to use. Next is the name of the application (.apk), and last is the alias to use for the private key.

Jarsigner prompts for the password to use the keystore and private key. An application can be signed more than one time by using different keys. For the applications which signed with the same private key can establish a trust relationship with each other and can run in the same process and share code and data.

Last step for command line signed process is to optimize the application. So the data boundaries are memory-aligned with respect to the start of the file, a technique that improve runtime performance and memory utilization. To align the application, use zipalign:


 * zipalign -v 4 your_project_name-unaligned.apk your_project_name.apk

Note:


 * v: indicates verbose output. The number 4 indicates to use four-byte alignment (always use four bytes).
 * The next argument is the filename of the input signed application (.apk), which must be signed with your private key, and the last argument is the output filename; if overriding an existing application, add -f.

In order to verify that the application has been signed we can use the Jarsigner by using the command line as shown below:


 * jarsigner -verify -verbose -certs my_application.apk

Note:


 * verify: indicates to verify the application;
 * verbose: indicates verbose mode;
 * certs: indicates to show the CN field of who created the key,
 * And last argument is the name of the Android application package to verify.

Now let have a look on how to create keys and certificate and sign and optimize your application. In order to generate the keys using the Eclipse ADT, there are two methods of exporting application from Eclipse:


 * Export an unsigned version of the application that you must manually sign
 * Export a singed version of the application, where the ADT does all the steps for you.

Unsigned version can be manually signed by using the command line as previously mention. To export an unsigned version of the application using the ADT, right-click the project and select Android Tools > Export Unsigned Application Package' (see figure 8 below)



Figure 8: Exporting the unsigned application.

To export signed application by using Eclipse ADT, by just simply right-click the project and select Android Tools > Export Signed Application Package(see figure 9 below).

You can export a signed version of the application. Using this approach, the ADT prompts you for the following required information:
 * The required information to use an existing KeyStore or create a new protected KeyStore
 * The required information to create a protected private key
 * The information needed to generate the public-key certificate



Figure 9: Exporting the signed application.

At this point, the Export Wizard executes, as in Figure 10



Figure 10: Export Wizard.

In Figure 11, select an existing keystore or create a new one and the credentials to use.



Figure 11: Export Wizard: Keystore selection.

In Figure 12, enter the information to create the private key and the digital certificate.



Figure 12: Export Wizard: Creating the private key and the digital certificate.

In Figure 13, enter the path and name for the destination file, and verify the validity period.



Figure 13: Entering the path and name for the destination file.

When finished, you have a release-mode signed and optimized application that you can publish. Alternatively, you can also invoke the Export Wizard using the Android Manifest Tool, as in Figure 14.



Figure 14: Invoking the Export Wizard using the Android Manifest tool.

After applications are signed, the next step is for you to define in the manifest the permissions needed by the application. This process is described next.

Application-defined and user-granted permissions
All Android application are running in an Application Sandbox. Android application can access to the limited range of system resources. Some capabilities are restricted by the lack of APIs to the sensitive functionality. For instance, there is no android API for directly manipulating the SIM (Subscriber Identity Module) card. In case, separation of roles can be provided a security measure. In other cases, the sensitive APIs are intended for use by trusted applications and protected through a security mechanism know as Permissions. Permissions are Android platform security to enable or disable application to access to restricted APIs and resources. Android applications have no permissions granted to access to protected APIs or resource on the device unless you allow the access permission in the application though the manifest file (AndroidManifest.xml) or granted or not granted by the user during installation.

The protected APIs include:
 * Camera
 * Location data (GPS)
 * Bluetooth
 * Telephony
 * SMS/MMS
 * Network/data connections

In case, the application attempt to use the above protected feature which has not been declared in the manifest file, the permission failure will result in a security exception being through back to the application.

To request permission, declare a attribute in the manifest xml file:


 * 


 * where the android:name specifies the name of the permission.

The full permissions list are described in the Manifest.permission. Application can declare their own permissions for other applications to use.



Figure 15: AndroidManifest.xml file.

Figure 14 above has told the system that the user grant to access the Internet and external storage. The full permission list can be found at


 * https://developer.android.com/reference/android/Manifest.permission.html.

We can also define their own custom permissions to protect application resources. Other application that want to granted access to this custom permission via their own manifest file. The figure 16 a customer permission is defined by specifying the minimum attributes name, description, label, and protectionLevel. When defining a permission a protectionLevel attribute tells the system how the user is to be informed of applications requiring the permission, or who is allowed to hold a permission. Other attributes can be added or defined for further usage.



Figure 16: Declaring a custom permission.

Applications are restricted to access the application and the system components such as Activities, Services, Content Provider, and Broadcast Receiver. It can be done by adding the attribute android:permission. As shown in the figure 17 below, this level of protection lets the application allow or restrict other applications to access the system resource.



Figure 17: Defining a permission to an activity.

Content providers and file permissions

Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security. Content providers expose a public URI (Uniform Resource Identifier) that uniquely identifies their data. In order to protect the data with content providers, all the resulting from a caller (activities) can be set the Inten.FLAG_GRANT_READ_URI_PERMISSION and Inten.FLAG_GRANT_WRITE_URI_PERMISSION, to grant the receiving activity permission to access the specific data URI in the intent.

Application files are protected by default. Files are protected based on user IDs and thus accessible only to the owner application, which has the same user ID. As previously covered, applications that share the same user ID (and are signed using the same digital certificate) run on the same process and thus share access to their applications. Applications can allow access of their files to other applications or processes. This allowance is made by indicating the proper MODE_WORLD_READABLEand MODE_WORLD_WRITEABLEoperating mode to allow read or write access to the file, or MODE_PRIVATEto open the file in private mode. You can specify an operating mode with the following methods when you create or open files:


 * getSharedPreferences(filename, operatingMode)
 * openFileOutput(filename, operatingMode)
 * openOrCreateDatabase(filename, operatingMode, SQLiteDatabase.CursorFactory)

Runtime PermissionAPIs

Android provides APIs to check, enforce, grant, and revoke permissions at runtime. These APIs are part of the android.content.Contextclass, which provides global information about an application environment. For example, if you want to handle permissions gracefully, you can determine whether your application has been granted access to the Internet (see Figure 18).

Figure 18: Using a runtime Permission API to check permissions at runtime.