Android Application Development basics: Application Fundamentals Chinese Translation of Android Dev Guide

Note: I recently joined the android Chinese translation group to provide better translation services. This section has completed the first draft and submitted for review and verification. The following is an incomplete version and is not recommended for reading. The final version will be released by the android Chinese team later. Please forgive me. Android Application Basics

The first translation, the translation of the wrong or not accurate place please correct, English original address: http://developer.android.com/guide/topics/fundamentals.html

Android applications are written in Java programming language. The android sdktool compiles the Code with another data source file into a compressed file (Android package) suffixed with .apk ). An APK file is an Android app. Android devices use an APK file to install Android apps.

Once installed on the device, each android application runs in its own secure sandbox:

● The Android operating system is a multi-user Linux system, and each application is a different user. (PS: I don't quite understand Linux)

● By default, the system assigns a unique Linux User ID to each application (this ID is only used by the system and is unknown to the application itself ). This ID is set by the system for access to all files in the application. Therefore, only applications with the assigned user ID can access these files.

● Each process has its own virtual machine, so the code execution of an application is separated from that of other applications.

● By default, each application runs in its own Linux Process. When an application or some components need to be executed, Android starts the process of the application. When the application no longer needs to be executed or the system must restore its memory for its application, the process is stopped.

In this way, the android system implements the principle of least privilege (the principle of least privilege ). that is to say, when each application only needs to complete its own functions without other services, it only has access to its own components by default. This creates a very safe environment because applications cannot access other parts of the system without permission.

However, applications can also share data with other applications and even access system services:

● It is possible for two applications to share the same Linux User ID so that they can access each other's files. To save system resources, applications with the same ID can run in one process and share virtual machines (these applications must use the same certificate ).

● Applications can apply for permission to obtain device data (such as user contacts, short messages, SD cards, cameras, and Bluetooth. All application licenses must be approved by the user during application installation.

The above describes the basic knowledge about how Android applications are executed in the system. The rest of this document will introduce you:

● Define the core framework components of an application.

● Manifest file, which is an application declaration component and required device features.

● Resources separated from application code, which allows your application to elegantly optimize its behavior through various device configurations.

Application Components

Application components are required for Android applications. Each component is a different portal for the system to enter your application. Although not all components are users' actual entry points and there are some dependencies between them, each component has its own entity, and plays a unique role-each is a unique building block that defines the overall behavior of your application.

There are four different types of application components. Each type has different design goals and defines how to create and destroy different lifecycles.

The following are the four application components:

Activities (activity)

Activity indicates a single screen with a user interface. For example, an email application may have an activity to display the list of new emails, another activity to write emails, and another activity to read emails. Although in an email application, these activities form a cohesive user experience (cohesive user experience, translated AWKWARDLY), each activity is independent of other activities. For example, a video app can start an email activity in the email application to share an image.

Implement an activity by inheriting the activity class. Read the activities Development Guide to learn more.

Services)

A service is a component that runs a long-term operation or executes a remote process in the background. Service does not provide a user interface. For example, a service can play music in the background when the user executes another application, or it does not block the interaction between the user and the activity and capture data through the network. Another component, such as activity, can interact with it by enabling, running, or binding a service.

A service is a subclass of a service class. Read the Services Development Guide to learn more.

Content Providers)

Content Providers manages the shared data of applications. You can store data in a file system, SQLite database, web, or any permanent storage location that your application can access. Through content provider, other applications can query or modify the data (if the content provider permits ). For example, the android system provides content providers for managing user contact information. Therefore, any licensed application can query part of the content provider (such as contactscontract. data) to read and write the information of a contact.

Content providers also helps read and write private and non-shared data of applications. For example, the note pad example uses a content provider to save notes.

A content provider inherits the contentprovider abstract class and implements a set of standard APIs that allow other applications to execute transactions. For more information, see content providers Development Guide.

Broadcast receivers (broadcast receiver)

A broadcast receiver is a component that responds to system-wide broadcast notifications. Many broadcasts are initiated by the system-for example, broadcast notifications that indicate that the screen is disabled, the power is insufficient, or the photos are captured. Applications can also initialize broadcasts. For example, a broadcast that tells other applications that data has been downloaded to a device and can be used by other applications. Although broadcast receivers does not display the user interface, they may create a status bar notification to notify the user when the broadcast will occur. However, the more common case is that the broadcast receiver is only used as the "Gateway" of other components, and it does very little work. For example, it may initialize a service to execute some work based on specific events.

A broadcast receiver is implemented by inheriting the broadcastreceiver class. Each broadcast is published as an intent object. For more information, see the broadcastreceiver class.

　　

A unique feature of the Android system design is that any application can start components of other applications. For example, if you want a user to use a camera to capture a photo, this function can be implemented by another application, and your application can use it without having to develop another activity to capture photos by yourself. You do not have to collaborate or even connect the code of the photo application. Instead, you just need to simply start the photo app to capture the photo activity. When the call is complete, the photo is passed into your application, and then you can use it. For users, cameras seem to be part of your application.

When the system starts your component, it starts the process of the application (if not running) and initializes the class required by the component. For example, if your app starts the activity of the photo app, the activity runs in the Process of the photo app, not in the Process of your app. Therefore, unlike most other systems, Android applications do not have a single portal (for exampleMain ()Function ).

Because the system runs applications in an independent process with file permissions and restricts access to other applications, your applications cannot directly activate components of other applications. However, the android system does. Therefore, to activate components of other applications, you must send a message to the system saying that you intend to start a special component. Then the system activates the component for you.

Component Activation

Among the above four component types, activities, services, and broadcast receivers are calledIntent. Intents connects independent components at runtime (you can think of them as messages that request actions from other components), regardless of whether the component belongs to your application or other components.

An intent is created as an intent object, which defines the activation of messages of the specified component or component type-intent can be displayed or implicitly.

For activities and services, intent defines the action to be executed (for example, to "View" or "send" Something) and may specify the data URI to be operated (except for other items, the component to be executed may need to know it ). For example, an intent may send a message to an activity to show an image or open a webpage. In some cases, you can start an activity to accept the result, that is, the activity can return the result through intent (for example, you send an intent to allow the user to select a contact and return it to you. The returned Intent includes the URI pointing to the selected contact ).

For broadcast receivers, intent briefly defines the announcement to be broadcast (for example, a broadcast indicating that the device has insufficient power only contains a string of known actions, suggesting "insufficient power ").

The following component type is left: content provider, which is not activated by intent. It is activated by a target request from contentresolver. The content interpreter directly processes all direct transactions of the content provider. Therefore, components that execute these transactions do not need to deal with the content provider. Instead, they call the contentresolver method. This leaves the abstraction layer (for security) between the content provider and the component request information ).

The following separation methods are used to activate each component type:

● You can pass an intent to startactivity () or startactivityforresult () (when you want the activity to return results) to start an activity (or let it do something new ).

● You can pass an intent to the startservice () method to start a service (or give a new command to a service being executed ). Alternatively, you can bind a service by passing an intent to bindservice.

● You can pass an intent to initialize a broadcast by using methods such as sendbroadcast (), sendorderedbroadcast (), or sendstickybroadcast.

● You can call contentresolver's query () method to execute a query.

For more information about using intent, see intents and intent filters. For more information about activating a specified component, see activities, services, broadcastreceiver, and content providers.