- Mobile Security Tutorial
- Mobile Security - Home
- Mobile Security - Introduction
- Mobile Security - Attack Vectors
- App Stores & Issues
- Mobile Security - Mobile Spam
- Mobile Security - Android OS
- Mobile Security - Android Rooting
- Mobile Security - Android Devices
- Mobile Security - Android Tools
- Mobile Security - Apple iOS
- iOS Device Tracking Tools
- Windows Phone OS
- Mobile Security - BlackBerry OS
- Mobile Security - BlackBerry Devices
- Mobile Security - MDM Solution
- SMS Phishing Countermeasures
- Mobile Security - Protection Tools
- Mobile Security - Pen Testing
- Mobile Security Useful Resources
- Mobile Security - Quick Guide
- Mobile Security - Useful Resources
- Mobile Security - Discussion
Mobile Security - Android OS
As many of us know, software is developed by Google for mobile devices with processing capabilities for smartphones and tablets. Its kernel is based on Linux. Its installed applications run in a sandbox. However, many producers have released its antiviruses for such OS, like Kasperky, MCAfee, and AVG Technologies. Even though antivirus application runs under sandbox, it has a limit to scan the environment.
Some feature of android OS are as follows −
- Dalvik virtual machine optimized for mobile device
- SQLite database for structured data
- Integrated browser based on WebKit engine
- Support of different media formats like audio, images, video
- Rich development environment like emulators (Bluestack), debugging tools
Android OS Architecture
The following image shows the overall architecture of Android OS −
The first layer is Application, includes applications such as SMS, calendars, and other third party applications.
The second layer is Application Framework, which includes −
View system, which is for developers to create boxes, lines, grids, etc.
Content providers permit applications to access and use data from third party applications.
Activity manager controls the life cycle of an application.
Resource manager allocates resources to an application.
Notification manager helps to shows notifications of applications.
The third layer is libraries, which is the most important part. It utilizes the function of the application, for example, to store date in a database. It is SQLite that utilizes this function.
The fourth layer is the Linux Kernel. It holds all the drivers of the hardware components, such as camera, wireless, storage, etc.
Android Device Administration API
The Device Administration API introduced in Android 2.2 provides device administration features at the system level. These APIs allow developers to create security-aware applications that are useful in enterprise settings, in which IT professionals require rich control over employee devices.
The device admin applications are written using the Device Administration API. These device admin applications enforce the desired policies when the user installs these applications on his or her device. The built-in applications can leverage the new APIs to improve the exchange support.
Here are some examples of the types of applications that might use the Device Administration API −
- Email clients
- Security applications that do remote wipe
- Device management services and application
The examples used in this tutorial are based on the Device Administration API sample, which is included in the SDK samples (available through the Android SDK Manager) and located on your system as
<sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/ DeviceAdminSample.java.
Sample Application
This sample application offers a demo of device admin features. It presents the users with a user interface that lets them enable the device admin application.
Once the users have enabled the application, they can use the buttons in the user interface to do the following −
Set password quality.
Specify requirements for the user's password, such as minimum length, the minimum number of numeric characters it must contain, and so on.
Set the password. If the password does not conform to the specified policies, the system returns an error.
Set how many failed password attempts can occur before the device is wiped (that is, restored to factory settings).
Set how long from now the password will expire.
Set the password history length (length refers to the number of old passwords stored in the history). This prevents the users from reusing one of the last passwords they previously used.
Specify that the storage area should be encrypted, if the device supports it.
Set the maximum amount of inactive time that can elapse before the device locks.
Make the device lock immediately.
Wipe device data (that is, restore factory settings).
Disable the camera.