Android Application Basics

 

Android applications are written in Java programming language. Android devices use this file to install applications.

 

Every android application installed on the device lives in its own security sandbox:

1. The Android operating system is a multi-user Linux system, in which each application is a different user.

2. By default, the system assigns a unique Linux User ID to each application (this ID can only be used by the system and is unknown to the application ). The system sets permissions for all files in the application so that only applications that match the user ID can access them.

3. Each process has its own virtual machine. Therefore, applications are isolated from each other.

4. by default, each application runs in its own Linux Process. When any application needs to be executed, Android starts the process, this process is disabled when it is no longer needed or when the system must restore memory for other applications.

 

The Android system implements the minimum privilege principle, that is, by default, each application can only access the necessary components that support its work. In this way, a secure environment is created, in which the application cannot access the part that is not authorized by the system.

 

However, there are also some ways for applications to share data and applications to access system services:

1. It is possible that two applications share the same Linux User ID so that they can access each other's files. To save system resources, applications with the same user ID can run in the same Linux Process and share the same Virtual Machine (applications must have the same digital signature)

2. applications can request the permission to access device data (such as the user's address book, SMS, installable storage device, camera, Bluetooth, etc ), the permissions of all applications must be granted by the user at the same time.

 

The rest of this article will introduce how Android applications exist and the basic knowledge in the system:

1. define the core framework components of the application;

2. Declare components and request device functions for the application in the manifest file;

3. separate application code from resources and allow applications to optimize their behavior using various device configurations.

 

Application Components

Application components are an important cornerstone of Android applications. Each component is a different portal for the system to enter applications. For users, not all components are actually portals, some of them are mutually dependent, but each component has its own entity and plays a special role-they are the only module that helps define the overall behavior of the application.

An application has four different types of components, each of which has a different purpose and defines how components are created and destroyed in different lifecycles.

 

The following are four types of application components:

Activites

An activity represents a separate screen with the user interface. For example, an email application can have an activity that displays the new email list, an activity that writes emails, and an activity that reads emails. Although these activities work together in the mail application to form a unified user experience, they are independent of each other. In this way, a different application can start any of these activities (if permitted by the mail application ). For example, a camera application can start the activity of writing new emails in the mail program to share an image to users.

 

An activity is implemented as a subclass of activity. You can learn more in the activities developer guide.

 

Services

A service is a component running in the background for long-time operations or remote processing. Service does not provide user interfaces. For example, a service may play music in the background, but users are using another different application. It can also be a service that obtains data from the network without the activity user interface.

 

Content Providers

Content Provider manages a shared application dataset, which can be stored in a file system (a local persistent storage medium that can be accessed by an SQLite database, on the network, or other applications) and other applications can query or edit data (if the content provider permits. For example, the android system provides a content provider for managing the user address book. In this way, any application with the appropriate authorization can query the data read/written by the content provider.

Content provider can also be used to read and write private data of an application rather than share it. For example, the note pad program uses a content provider to save comments.

Content Provider is implemented as a subclass of contentprovider, and a set of standard APIs must be implemented to enable other applications to execute transactions.

 

Broadcast receivers (broadcast receiver)

Broadcast receivers is a component that responds to system-wide broadcast notifications. The system has many broadcast sources, such as a broadcasting notification for screen shutdown, a notification of insufficient battery power, and a screenshot notification. Applications can also start broadcast, such as letting other applications know that some data has been downloaded to the device, and the application can be used effectively. Although broadcast receivers does not display user interfaces, they can create status bar notifications to remind users that a broadcast event has occurred. More often, broadcast receivers serves only as a gateway for other components and does little work. For example, it can start a service that executes tasks based on events.

 

Broadcast receiver is implemented as a subclass of broadcastreceiver, and each broadcast is distributed as an intent object.

 

The unique design side of the Android system is that any application can start components of another application. For example, if you want to take a photo using a camera device, you may take a photo in one application and use the photo in another application, you do not need to develop an activity for taking photos in your own application. You do not need to merge or link events to the code from the camera app, but simply start the activity used for photography in the camera app. When the photo is taken, the event is returned to your application so that you can use the photo. For users, the camera application is like a part of your application.

 

When the system starts a component, it starts the process of that application (if the application is not running) and initializes the class required by the component. For example, if your application starts the activity used for taking photos in the camera application, the activity runs in the Process of the camera application, not in your own process. Therefore, unlike most other systems, Android applications do not have a separate entry point (for example, there is no main () method ).

Because the system runs each application in a process that restricts access to other application files, the application cannot directly activate components from other applications. However, the android system can do this. To activate a component in another application, you must send a message to the system, specify the specific component to be started, and then activate the component for you.

 

 

Activate Components

Three of the four types of components (activities, services, and broadcast receivers) are activated through asynchronous messages called intent. Intents is bound to independent components at runtime (you can think of it as an action messenger for requests from other components), regardless of whether the components belong to the application or other applications.

An intent is an intent object. It defines a message, which can activate a specified component or a specified component type. An intent can be both explicit and implicit.

 

For activities and services, an intent defines the action to be executed (for example, browsing or sending ), you can also specify the data location (this information may be required for components that are being started ). For example, an intent may send a request, asking an activity to display an image or open a Web page. In some cases, you can also start an activity to receive a result. This activity also returns the result in intent (for example, you can send an intent so that you can select a personal contact method, the returned Intent includes a location pointing to the selected contact method .).

 

For broadcast receivers, intent simply defines broadcast notifications (for example, a broadcast that indicates insufficient power of the device contains only one string of known behavior: insufficient battery .).

 

Another component type-content provider is not activated using intents. It is activated when a contentresolver Object Requests the target. The content parser uses the content provider to process all direct transactions so that the component does not have to use the content provider to execute transactions, but calls methods on the contentresolver object. In this way, an abstraction layer is formed between the content provider and the component request information.

 

Each type of component has an independent method for activation:

1. by passing an intent to startactivity () or startactivityforresult () (this method is called when the activity returns a result), you can start an activity (or let the activity do something new .)

2. by passing an intent to the startservice () method to start a service (or sending a new command to a running service), you can also pass an intent to bindservice () method to bind a service

3. A broadcast can be started by passing an intent to sendbroadcast (), sendorderedbroadcast (), and sendstickybroadcast;

4. Call the query () method on contentresolver to execute a query on the content provider.

 

For more information about using intents, see intents and intent filters ). More information about activating a specific component is also provided in the following documents: activities, services, broadcastreceiver, and content providers.

 

Configuration File

Before starting an application component, the android system must read the androidmanifest. xml file of the application to understand the component existence. The application must declare all the components it uses in this file, which must be in the root directory of the application project directory.

 

In addition to declaring application components, the configuration file also does many other things, such:

1. Identify the user permissions required by the application, such as Internet access or user contact access;

2. Declare the minimum API level required by the application, that is, to indicate that the application uses the android API based on that level;

3. Declare the functions of hardware and software used or required by the application, such as cameras, Bluetooth services, or multi-touch;

4. api library links required by applications (except for Android framework APIs), such as Google map class libraries.

 

 

Declare Components

The main task of listing (manifest) is to notify the components of the system application. For example, the listing file can declare an activity as in the following example:

<? XML version = "1.0" encoding = "UTF-8"?>
<Manifest...>
<Application Android: icon = "@ drawable/app_icon.png"...>
<Activity Android: Name = "com. example. Project. exampleactivity"
Android: Label = "@ string/example_label"...>
</Activity>
...
</Application>
</Manifest>

 

In the <Application> element, the Android: icon attribute specifies an icon that identifies the application.

In the <activity> element, the Android: Name attribute specifies the complete Class Name of the activity subclass. The Android: Label attribute specifies a string tag for the activity to display to the user.

All application components must be declared using the following method:

1. The <activity> element is used to declare activities.

2. The <service> element is used to declare services.

3. The <receiver ER> element is used to declare broadcast receivers.

4. The <provider> element is used to declare content providers.

Activities, services, and content providers contained in the source code are not declared in the inventory file and are invisible to the system, so they cannot be run. However, broadcast receivers can be declared in the configuration file or dynamically created in the Code (such as the broadcastreceiver object), and then registered in the system by calling the registerreceiver () method.

 

For more information about the configuration file structure of an application, see the androidmanifest. xml file document.

 

Ability to declare Components

As discussed in the activating components section, you can use an intent to start activities, services, and broadcast receivers. You can do this by explicitly specifying the name of the target component in the intent (using the Class Name of the component. However, the actual ability of intent lies in the concept of intent behavior. Using intent behavior, you can briefly describe the type of behavior you want to execute (and the optional type of description is the data you need to describe the behavior you want to execute ), the system allows the system to find and start a component that can execute behaviors on the device. If there are multiple components that can execute the behaviors described by intent, you can choose to use one of them.

 

The system compares the intent received by the intent filter provided in the inventory file of other applications on the device to identify an intent that the component can respond.

 

When a component is declared in the Application List, the intent filter with declarative component capabilities can be selectively included to respond to intent from other applications. By adding a <intent-filter> sub-element to the declared element of the component, you can declare an intent filter for the component.

 

For example, an email application that uses an activity to write emails may declare an intent filter in its list to respond to "send" Intents (to send emails). Then, an activity in the application can create an intent with the "send" action. If you call the intent using startactivity () method, the system will match the "send" activity of the mail application, and load it.

 

For more information about creating an intent filter, see the intents and intent filters documents.

 

Declare application requirements.

Android supports many devices, and all these devices provide different functions. To prevent applications from being installed on hardware devices that lack the features required by the application, you can declare the device and software requirements in the application inventory file, this allows you to clearly define an overview of the device types supported by an application. Most of these declarations are information-based, and the system does not read them. However, other services (such as Android Market) are used to provide users with filtering services, this information is searched on the user's device.

 

For example, if an application needs to use APIs (API level 7) in camera and android2.1, it should declare these requirements in the application's configuration file. In this way, devices that do not have a camera and whose Android version is earlier than 2.1 will not install the app on the Android Market.

Although you can declare that your application uses a camera, it is not necessary. If it is not declared, your application must perform some checks at runtime, determine whether a device has a camera function. If the camera function is invalid, disable some related functions in the application.

 

Here are some of the device features that should be taken into consideration when designing and developing applications:

Screen Size and resolution

To differentiate devices by screen type, Android defines two features for each device: screen size (physical size of the screen) and screen resolution (physical density of points on the screen, or DPI --- points per inch ). To simplify all the configurations of different screen types, the android system summarizes them into a selection group that is easier to locate.

The screen size is small, normal, large, and super large;

The screen resolution is: low resolution, medium resolution, high resolution and ultra-high resolution.

By default, the application is compatible with all screen sizes and resolutions, because the Android system will adjust your UI layout and image resources accordingly. However, for fixed screen sizes, you should create specific la S and provide specific images for specific resolutions. You can also use layout resources, the <supports-screens> element is used in the Application List to explicitly declare the screen sizes supported by the application.

For more information, see the supporting multiple screens document.

 

Input Configuration

Many devices provide different user input mechanisms, such as keyboards, trackballs, or five-way navigation boards. If your application requires a special input hardware type, it should be declared in the <uses-configuration> element of the list. However, there is little need for explicit input configuration for applications.

 

Device features

Many hardware and software functions exist or do not exist on a given Android device, such as camera, brightness sensor, Bluetooth, a version of OpenGL, or touch screen accuracy. You should not assume that a function is valid on all Android devices (except for standard Android class libraries ), therefore, you should use the <uses-feature> element to declare all functions used by the application.

 

Platform version

Different Android devices often run versions of different Android platforms, such as android1.6 or android2.3. each subsequent version usually includes additional invalid APIs in the previous version. To specify the validity of the APIS set, each platform version specifies an API level (for example, the API level of android1.0 is 1 and the API level of android2.3 is 9 ). If you use any APIs added later than Version 1.0, you should use the <uses-SDK> element to declare the minimum API level.

 

It is essential to declare all these requirements for your application. When you publish an application to the Android Market, market uses these declarations to filter out valid applications on each device. Because of this, your application is only valid for all devices that meet your application requirements.

 

For more information about how Android Market filters applications based on these requirements, see the market filters documentation.

 

Application Resources

An android application is only composed of code. It must be independent of resources outside the code, files, audio files, and any visual representation of the application. For example, you should use an XML file to define the animation, menu, style, color, and activity layout of the user interface. Using application resources makes it easier to update various functions of an application without having to edit the code by improving the optional resource set. Allows you to optimize applications (such as different languages and screen sizes) for various device configurations ).

 

For each type of resources contained in your android project, the SDK compilation tool defines a unique digital ID, you can use the ID defined in the XML file to reference this resource in the application code or other resources. For example, if the application contains an image file named logo.png (saved in the Res/drawable/directory), the SDK generates an image file named R. drawable. resource ID of the logo, which can be used to reference the image and insert it into the user interface.

 

One of the important reasons for separating resources from Code is to provide optional resources for different device configurations. For example, by defining UI strings in an XML file, you can translate these strings into other languages and save them to an independent file, then, based on a language pre-selection tool (the name of the Resource Directory you append, such as the French string saved in the Res/Values-fr/directory) and the user's language settings, the Android system uses the appropriate language string in the UI.

 

Android supports many pre-selection devices for different resource selection. The pre-selection tool is a short string contained in the Resource Directory Name to define which resources should be used for device configuration. For example, you should create different la s for the activity based on the orientation and size of the device screen. When the screen height of the device is vertical, you may want the vertical layout of buttons. When the screen width is horizontal, you may want horizontal button layout. To rename the dependency orientation layout, you can define two different la S and use the directory name of each layout as the corresponding pre-selection tool. Then the system will change the layout according to the orientation of the current screen, the corresponding layout is automatically used.

 

For more information about the types of resources that an application can contain and how to create optional resources for different device configurations, see application Resource Development Guide.