Android Application Fundamentals

Write. Android.developer

Android applications are written in the Java programming language. The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file that Android-powered devices use to install the application.

Once installed on a device, each Android application lives in its own security sandbox:

• The Android operating system is a multi-user Linux system in which each application is a different user.
• By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
• Each process has its own virtual machine (VM), so an applications code runs in isolation from other applications.
• By default, every application runs in its own Linux process. Android starts the process when any of the applications components need to be executed, then shuts down the process when its no longer needed or when the system must recover memory for other applications.

In this way, the Android system implements the principle of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an application cannot access parts of the system for which it is not given permission.

However, there are ways for an application to share data with other applications and for an application to access system services:

• Its possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each others files. To conserve system resources, applications with the same user ID can also arrange to run in the same Linux process and share the same VM (the applications must also be signed with the same certificate).
• An application can request permission to access device data such as the users contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All application permissions must be granted by the user at install time.

That covers the basics regarding how an Android application exists within the system. The rest of this document introduces you to:

• The core framework components that define your application.
• The manifest file in which you declare components and required device features for your application.
• Resources that are separate from the application code and allow your application to gracefully optimize its behavior for a variety of device configurations.

Application Components

Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your applications overall behavior.

There are four different types of application components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed.

Here are the four types of application components:

Activities

An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email application, each one is independent of the others. As such, a different application can start any one of these activities (if the email application allows it). For example, a camera application can start the activity in the email application that composes new mail, in order for the user to share a picture.

An activity is implemented as a subclass of Activity and you can learn more about it in the Activities developer guide.

Services

A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.

A service is implemented as a subclass of Service and you can learn more about it in the Services developer guide.

Content providers

A content provider manages a shared set of application data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the users contact information. As such, any application with the proper permissions can query part of the content provider (such as Android应用基础

一旦安装在设备上，每个Android应用程序的生命在它自己的安全沙箱：

默认情况下，每个应用程序的系统会被分配一个唯一的Linux用户ID（该ID仅用于由系统并且是个未知的应用程序），系统设置所有的应用程序中的文件权限，以致于只有用户ID分配给该应用程序时才可以访问它们。

默认情况下，每个应用程序运行在它自己的Linux进程中。在Android的启动过程时，应用程序的任何组件需要被执行，当它不再被需要或系统必须为其他应用程序重置内存时，才会被关闭。

然而，会有些方法使得应用程序能够与其他应用程序分享数据以及为应用程序提供系统服务通道：

应用程序可以请求访问设备数据，比如用户的联系人，短信，可使用的存储（SD卡），照相，蓝牙等，所有应用程序的权限必须由用户在安装时授予。这包含了基本问题如Android应用程序如何存在系统中。接下来其余部分向您介绍：

2、清单文件中声明组件和应用程序所需的设备功能。

应用程序组件（Application Components）

有四种不同类型的应用程序组件，每一种类型都有一个明确的目的，并有着不同的生命周期，这些生命周期它定义了组件是如何创建如何销毁的。

活动(Activities)

activity 是一个实现了 Activity 的子类，你可以在 Activities 开发者指导部分了解更多。

服务(Services)

service 是在后台运行，它执行长时间操作或者执行远程操作。service不提供用户界面。例如，当用户在另一个应用程序时，一个service可在后台播放音乐，又或者是从网络上获取数据，此时不会不切断用户与当前activity的交互。在其他组件中，比如一个activity为了与service进行链接，会启动service让它可以运行或者约束。

service 是一个实现了Service 的子类，你可以在 Services 开发者指导部分了解更多。

内容提供者(Content providers)

内容提供者管理一套共享的应用程序数据。数据可以存储于文件系统、SQLite数据库、网站或任何应用允许持续存储的的空间中。尽管内容提供者content provider作用大，其他的应用程序能够查询甚至修改数据(如果content provider允许的话)。比如，Android系统提供一个内容提供者content provider去管理用户的相关信息。再比如，任何有适合的允许权的应用程序能够查询content provider的一部分(比如ContactsContract数据库)来读写相关的个人信息。

Content providers也是有利于读写应用程序中私有不是共享的数据，比如Note pad应用程序使用了content provider去保存笔记。

一个content provider是ContentPrvoider实现的基类，也必须要实现一套APIS制定的标准，这个标准允许其他的应用程序进行交互，为其它应用程序取用和存储它管理的数据实现了一套标准方法应用程序并不直接调用这些方法，而是使用一个对象，调用它的方法作为替代。更多的信息可以去查阅Content Providers开发指导部分。

广播接收器(Broadcast receivers)

广播接收器broadcast是一个组件，它专注于回应系统广播通知信息。很多广播是源自于系统──比如，广播通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以进行广播──比如说，通知其它应用程序一些数据下载完成到设备中并处于可用状态。尽管广播接收方不会显示为一个用户的接口，但是当广播出现时，他们能够创造状态栏来通知用户相关信息，更为普遍的是，虽然对于其他的组件，广播接收器仅仅是一个入口，并且只占用少数的工作量。比如，广播接收器可能是种服务，为了告知一些基于工作的状态。

应用程序可以拥有任意数量的广播接收器以对所有它感兴趣的通知信息予以响应。所有的接收器均继承自BroadcastReceiver基类，每个广播接收器被当做一个目的类传送，更多的信息可以参考BroadcastReceiver类。

Android系统设计的一个独特方面是任何的一个程序都可以启动另一程序的组件。比如，你想让用户的程序可以使用照相机拍照，你没必要链接到照相机应用程序的代码。反而，你可以简单地开始相机应用程序捕捉到照片的Activity，也就是说你就没有再要再写一个新的Activity来实现这个功能。你的程序不需要包含或者链接这个拍照程序。甚至当拍完之后，拍好的照片会自动返回给你的程序，这样你就可以去使用它。对于用户来说，就好像是想拍照功能的程序就是你的这个程序的一部分一样。

当系统启动一个组件之后，系统会自动开始这个程序的进程(如果这个组件所在的程序之前没有运行的话)，并初始化这个组件所需要的相关类。例如，你的程序在相机应用程序开启了能捕捉到照片的功能的Activity，这时系统会启动这个Activity所在的程序，所以这个Activity运行在拍照功能的程序当中，而不是在你的程序中。因此，不像大多数其他操作系统的中的程序应用一样，Android应用程序没有一个单独独立的入口点（比如没有我们常见的main()函数）。

因为系统中的程序运行在自己的独立进程中，在这个单独的过程中，程序中的文件都有自己的权限，会限制其他程序访问的权限，所以，你的应用程序不能直接激活其他程序中的组件。然而，Android系统就可以。具体是这样的实现的，在另一个应用程序中激活其他程序中的组件，你必须向系统发送一个消息来详细说明你要启动这些组件的意图，这样系统才会为你激活这个组件。

激活组件(Activating Components)

四大组件中的三个组件——activities(活动)、services(服务)和broadcast receiver(广播接收器)——是由一种叫intent的异步消息来激活的。这些intents在运行时将这些属于你的程序或不同程序的单独的组件结合在一起(你可以把这些intents看作是需要其他组件的动作使者)。

一个intent就是一个Intent对象，这个intent定义了一种消息，它可以激活某个特定组件或者某种特定类型的组件，这两种情况对应两种intent的定义方式，分别是显示的或者隐式的。

对于activities和services，一个intent定义了要执行的操作(比如，要“视图”或者“发送”什么)，可以指定操作数据的URI(在其他的事件中，将要启动组件需要的东西)。比如，一个intent可能会为一个activity传递一个请求来展示一张图片或者打开一个网页。在某些情况下，你可以启动一个activity来得到返回的结果，此时这个activity的返回的结果也是一个Intent（比如，你可以发送一个intent让用户选择一个个人的接触，并返回给你——这个返回的intent就包含了一个指向用户选择的联系人的URI）。关于activity和service的启动方式，下面将介绍。

对于广播接收者来说，intent只是简单的定义了要广播的内容（比如，一个用以表明电池电量很低的广播，仅包含了一个表明“电池电量很低”的字符串）。

最后一种组件类型content provider并不是由intent来激活的。相反，它是由接收到ContentResolver的请求时才会激活的。

它们都各自有自己的方法来激活相应的组件：

1.你可以通过传递一个Intent给startActivity()或startActivityForResult()启动一个activity（或者给他一些新的要做的内容）(当你想Activity返回结果时)。

2.你可以通过传递一个Intent给startService()来启动一个service（或者给一个正在运行的service一些新的指令或者指示时）。或者你可以通过把一个Intent传递给bindService()来绑定一个service。

3.你可以通过传递一个Intent给诸如sendBroadcast()、sendOrderedBroadcast()或者sendStickyBroadcast()等方法来初始化一个广播。

4.你可以通过调用ContentResolver的query()方法来执行一次content provider的查询操作。

更多的关于intent的内容，可以参看文档中的Intents and Intent Filters。更多的关于激活特定组件的内容可以参看文档中的：Activities、Services、BroadcastReceiver、Content Providers。

关于Manifest文件（The Manifest File）

在Android系统可以启动一个应用程序组件之前，Android系统必须通过读取这个程序的AndroidManifest.xml（即manifest“清单”文件）文件来确定要启动的组件存在。你的程序必须在这个manifest文件声明用到的所有的组件中，并且这个manifest文件必须在项目的根目录下。

另外，这个manifest文件还声明一些其他应用程序的信息，比如：

1.确定这个应用程序所需要的所有权限，比如Internet访问权限或者读取用户联系人权限。

2.声明这个运行这个程序所需要的最低API版本，这个可以根据开发程序所使用的API版本。

3.声明该程序所需要的硬件或软件特征，比如照相机、蓝牙服务或者多点触屏。

4.声明该程序需要链接的API库(不是Andorid框架中的API)，比如谷歌地图图书馆。

5.等等。

组件声明<!--

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[152398]，资料为PDF文档或Word文档，PDF文档可免费转换为Word