An overview of the 2.Android application Fundamentals of the "Official Archive of Books"

Official Documents original Address

Application Principles

Android applications are written in the Java programming language. The Android Software development tool compiles and packages your code and other data and resource files together into an apk file, which uses the. apk suffix to save all the content of an Android app, which the Android device uses to install the corresponding app.

Once installed on the device, each Android application runs in its own separate security sandbox:

1. The Android system is a multi-user Linux system, and each application is a user.
2. The Android system assigns a unique user ID to each app by default (this ID is only used by the system and is not known by the app). The system sets permissions on all files corresponding to each app, and only the app with the correct user ID can access it.
3. Each process has its own virtual machine, so that one application code can run independently and not be interfered with by other applications.
4. By default, each app runs in its own standalone Linux process. When a component in an application needs to be executed, the system will open its process. This process is closed when there is no activity in the process or if the system is running out of memory and requires the shutdown process to reclaim memory for other applications.

Each app runs in its own separate sandbox, in such a way that the Android system implements the principle of least privilege-that is, each app defaults to access to the resources it needs to work with (translator Note: Note Here is the default, in many cases we need to access resources for other applications, This is the time to use another key technology, "process communication". This creates a very secure environment in which an application cannot access files that it does not have permissions for.

However, the system also provides some ways to share data and application access to system services among applications:

1. We can share the same Linux user ID for two apps so that they can access each other's files. To conserve system resources, applications with the same UID can run in the same Linux process, using the same virtual machine, provided that the applications must have the same signature.
2. An app can request access to device data, such as a user's contacts, text messages, SD cards, cameras, Bluetooth, and so on. Users can decide whether to grant these permissions to the app.

The above outlines the principles of how Android applications exist in the system. The following describes:

1. Building the core framework components of your application
2. declaring components and requesting device features for your app in the manifest file
3. The most elegant resource that separates your app from the code and allows your application to perform in many device configurations

Application components

Application components are the necessary modules for building an Android program. The system can enter your application through components of different components. Not all component users can see and feel, some components need to rely on other components to start, but they exist as an independent individual, and play a different role to help you decide what your application behavior.

There are four types of application components, each of which has its own unique functionality, as well as a lifecycle that determines how it is created and destroyed.

Here are four different types of application components:

2. Activity
   An activity represents an interface. For example, an e-mail application might have a real activity for a new mailing list, an activity to create a message, and an activity to read a message. These activities work together to form a complete e-mail user experience, while each activity is independent of each other, so other apps can invoke the above several (if this email app allows). For example, a camera app that allows users to share photos, can start the activity that creates the message directly.

4. Services
   A service is a component running in the background that is commonly used for long-time operations or for cross-process operations. The service does not provide a user interface. For example, the service can play music in the background while the user is using another app, or it can request data from the server in the background without interfering with user interaction. Other components, such as activity, can start a service, or bind to a service to allow interaction to occur.

6. Content Providers
   Content provider manages a set of shareable application data. You can store the data in a file system, a SQLite database, a network, or any other place where your application can access persistent storage. With content provider, other apps can query and even modify data (if the content provider allows). For example, the Android system provides a content provider that manages user contact information. By using it, any app can query the content provider's part as long as it has permission, and then read or write specific contact information.
   The Content provider can also be used to read and write application-private data.

8. Broadcast receivers
   Broadcast receivers components that can respond to all broadcasts. Many broadcasts are sent by the system, such as a broadcast notification when the screen is off, a broadcast when the battery is low, or a photo-finished broadcast. Applications can also create broadcasts, such as sending a broadcast to let other programs know that data has been downloaded to the device and is ready for use. Although the broadcast recipient does not have an interface, it can create a notification in the status bar to notify the user when a broadcast event occurs. Usually the broadcast recipient is just a portal to do a few other components and does very little work. For example, when you receive a broadcast, start a service to perform some operations.

One of the unique features of the Android system design is that any application can launch components for other applications.

For example, you want users to use the device's camera to take a picture, the device has a special application to do this function, you do not need to write a camera application, simply call the system camera application can be photographed. When you're done, you'll get back the data for the photos you want to use. For the user, it looks like the camera is part of your app.

When the system launches a component, a separate process is started for the application (if the app is not started), and then some classes are instantiated. For example, your app launches the activity of the photo app, which runs in the process where the camera app resides, not the process of your app. Therefore, unlike other platform system applications, Android apps have not only a portal (not the main method in Java).

Because the system runs each application in a different process and restricts access to other application files, your app cannot directly activate the components of other apps. However, you can call the components of the Android system directly. To activate the components of another application, you must indicate in your intent that the system is launching a specific component. The system will activate that component for you.

Activating components

Three of the four components: activities, services, broadcast receivers can be activated by calling intent asynchronously. Intent calls and called components at run time (which can be understood as when a request calls another component), regardless of whether the component belongs to your app.

The intent object is used to create a intent that intent can decide whether to activate a particular component or activate a class of components. Intent can be divided into 2, explicit and implicit.

For activities and services, a intent determines the behavior to invoke (for example, to display or send something), or it may indicate a URI to use the data (the called component may need to enter some data). For example, a intent may make a request to have an activity show a photo or open a Web page. Sometimes when you start an activity you may also need to receive a return result, in which case the activity returns the result in a intent (for example, you can launch a intent that lets the user select a contact and then return the information to you, The returned intent may include a URI that points to the selected contact.

For broadcast receivers, intent simply defines the announcement to receive the broadcast (for example, a broadcast that wants to receive a low-power device can simply indicate a "low" action in intent).

Additional components are –content provider and cannot be intent activated. It is activated by a request made against the content resolver. This content resolver handles all the direct transactions of the content provider, so the component does not need to call provider, but calls the content resolver method directly. This preserves a middle tier between the content provider and component requests, which is more secure.

Here are a few different ways to activate different types of components:

1. By giving StartActivity () or Startactivityforresult () when you want to open an activity or pass new data to an activity that has already been activated. (When you want to receive a return result) the method passes a intent.
2. When you want to open a service or give a running service a new command, you can bind to the service by passing a intent to the Starservice () method or passing a intent to Bindservice ().
3. You can instantiate a broadcast by passing in a intent to the Sendbroadcast (), Sendorderedbroadcast (), Sendstickybroadcast () method.
4. Perform a query operation on the content provider by calling the Contentresolver query () method.

The Manifest file

To enable an Android system to launch an application component, the system needs to know whether the component exists by looking at the app's Androidmanifest.xml file. Your app must declare all the components in this file in the application code root directory.

The manifest also does a lot of things besides declaring application components, such as:

• Identify the user rights that the app will use, such as accessing the network or accessing the user's contacts;
• Declare the user's minimum mobile version required by the application;
• Declare the hardware and software features required by the application, such as camera, Bluetooth or multi-touch screen;
• Declare the API library (not the Android frame interface) to be used, such as the Google Maps interface.

The activities,services you use, and the content providers if not declared in manifest, are not available to the system and therefore cannot be run. However, broadcast receivers has two options, either in manifest or in the code (creating a Broadcastreceiver object and then calling Registerreceiver () to register).

Intent filter that declares the capability of a component

As mentioned above, you can use a intent to start activities,services,broadcast receivers. You can explicitly use the class name of the component in intent to specify the component to invoke. The real intent, however, is the concept of implicit invocation. An implicit intent simply describes the type of behavior to be executed (you can also pass data to the behavior you want to invoke), allowing the system to find a component that can perform the behavior you require and then turn it on. If more than one component can perform the behavior described in intent, the user needs to choose which to use.

How does the system find the components of your intent call? The answer is by comparing the intent filters tags of the components in the manifest file of other apps on the device.

When you declare an activity in the app's manifest, you can also add a intent filter tag to the activity that declares the activity capability, and the activity can respond to other applications. You can add a intent filter to your component by adding a label to the component's label.

For example, if you create a mail application that requires an activity to create a new message, you can declare a intent filter in the activity to respond to the intent of the Send (new message), such as:

... >    ...    ... >        <activity android:name="com.example.project.ComposeEmailActivity">            <intent-filter>                <action android:name="android.intent.action.SEND" />                <data android:type="*/*" />                <category android:name="android.intent.category.DEFAULT" />            </intent-filter>        </activity>    </application></manifest>

If there are other apps that create a intent with action_send action and then start with startactivity (), your activity may start, and then the user can edit and send an email.

Declaring application Configuration Requirements

There are too many types of devices on the market that are equipped with Android, and these devices have different hardware configurations. To prevent your application from being installed on a phone that does not have the configuration you require, you need to indicate the hardware and software configuration required by your application in the manifest file. Usually these lives are used only to hint that the mobile phone system will not be browsed, but third-party service providers such as the Google App market will browse them and then help users filter apps that have additional configuration requirements when they download the app.

For example, if your application requires a webcam and requires a minimum device configuration of Android2.7 (API Level7), you need to indicate this in manifest:

... >    <uses-feature android:name="android.hardware.camera.any"                  android:required="true" />    <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" />    ...</manifest>

It has been stated that devices that do not have a webcam or Android version below 2.1 will not be able to install your app on the Google app market.

You can also declare in your app that you want to use a webcam but not required. In this case your app must set the Required property in the above tag to false, and then check to see if the device supports the camera while it's running, and if not, disable camera-related operations.

Introduction to Application Resources

An Android app is not just composed of code, it also has a lot of resources other than code, such as pictures, audio files, or other things related to the application display. For example, you need to define animations, menus, styles, colors, and layout files for interactive interfaces, and so on. Using the app resource file makes it easier to update something without modifying the code and replacing the corresponding resource file directly. This allows your application to adapt as much as possible to different device environments (such as different languages or different screen sizes).

For each resource in your project, the Software development tool will give it a unique integer ID that you can reference from your code or other resource file. For example, your app contains a picture file named Logo.png (saved in the res/drawable/directory), and the SDK generates an ID called R.drawable.logo, which you can use to refer to the logo image and insert it into the interface.

One of the most important benefits of providing resource files that are separate from source code is that you can provide different resource files for adapting to different devices. For example, in XML, you define the characters in the interface, you can prepare these characters in different languages, and store them in different files. Then the system will be based on the user device settings in the language, the file in the same folder suffix name to find the appropriate characters to display (such as the French characters stored in the res/values-fr/, when the user system language is French, the folder will display the characters stored under it).

Android supports many different ways of selecting resources. This choice depends primarily on the character suffix in the name of the resource folder you created in order to use different resources under different configurations. To raise a chestnut, you should be accustomed to creating different layout files for your activity depending on the screen size or orientation of your device. When the device screen is vertical, there is a button in your layout, and when the screen is turned into a horizontal screen, you want this button to go to the horizontal screen. To make the layout change with the screen orientation, you can define 2 different layouts, and then place each layout in a different folder that is appropriate and can be selected correctly. The system will automatically load the appropriate layout based on the screen orientation.

An overview of the 2.Android application Fundamentals of "the Official books"