Android Application Fundamentals
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:
1、The core framework components that define your application.
2、The manifest file in which you declare components and required device features for your application.
3、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
剩余内容已隐藏，支付完成后下载完整资料
安卓应用基础
Android应用程序是用Java编程语言编写的。Android SDK工具把应用程序的代码、数据和资源文件一起编译到一个Android程序包中（这个程序包是以.apk为后缀的归档文件），一个Android应用程序就是一个单独.apk文件中的所有内容，并且Android设备使用这个文件来安装应用程序。
安装在设备上的每个Android应用程序都生活在它们自己的安全沙箱中：
1. Android操作系统一个多用户的Linux系统，在这个系统中每个应用程序都是一个不同的用户。
2. 默认情况下，系统给每个应用程序分配一个唯一的Linux用户ID（这个ID只能被系统使用，并且对于应用程序是未知的）。系统给应用程序中的所有文件设置权限，以便只有跟用户ID匹配的应用程序能够访问他们。
3. 每个进程都有它们自己的虚拟机，因此应用程序的运行是彼此隔离。
4. 默认情况下，每个应用程序运行在它们自己的Linux进程中，当任何应用程序需要被执行时，Android启动这个进程，在不再需要的时候或系统必须为其他应用程序恢复内存时这个进程被关闭。
Android系统实现了最小特权原则，也就是说，默认情况下，每个应用程序只能访问支持它工作的必须的组件。这样就创建了一个安全的环境，在这个环境中应用程序不能访问系统没有给它授权的部分。
但是，还有一些应用程序间共享数据和应用程序访问系统服务的方法：
1. 两个应用程序共享相同的Linux用户ID是可能的，这样它们就能够访问彼此的文件。为了节省系统资源，拥有相同用户ID的应用程序也可以运行在相同的Linux进程中，并且共享相同的虚拟机（应用程序必有拥有相同的数字签名）
2. 应用程序能够请求访问设备数据的权限（如用户的通讯录、短信、可安装的存储设备、照相机、蓝牙等等），所有的应用程序的权限都必须在按照时被用户授予。
在这篇文章的剩余部分会介绍Android应用程序是如何存在与系统中的基础知识：
1. 定义应用程序的核心框架组件；
2. 在manifest文件中为应用程序声明组件、请求设备功能；
3. 把应用程序的代码与资源分离，并且允许应用程序使用各种设备配置优化它们的行为。
应用程序组件
应用程序组件是Android应用程序的重要基石，每个组件都是系统进入应用程序的不同入口，对于用户来说，不是所有的组件都是实际的入口，并且有一些是彼此依赖的，但是每一个组件都存在它们自己的实体，并且扮演着特殊的角色---它们都是帮助定义应用程序整体行为的唯一的模块。
应用程序有四种不同类型的组件，每种类型服务一个不同的目的，并且有一个定义组件如何创建和摧毁不同的生命周期。
以下是应用程序组件的四种类型：
Activites
一个Activity代表一个和用户接口的单独屏幕。例如，一个email应用程序可以有一个显示新邮件列表的Activity，一个写邮件的Activity和一个读邮件的Activity。在邮件应用程序中虽然这些Activity一起工作，从而形成统一的用户体验，但是它们是彼此独立的。这样，一个不同的应用程序能够启动这些Activity中的任何一个（如果邮件应用程序允许）。例如，一个相机应用程序为了给用户共享一张图片，可以启动邮件程序中编写新邮件的Activity。
一个活动是作为一个Activity子类实现的，可以在Activities开发者指南中学到更多的内容。
Services
Service是一个运行在后台的组件，用于执行长时操作或执行远程处理工作。Service不提供用户接口。例如，一个Service可能在后台播放音乐而用户却在使用另一个不同的应用程序，也可以是一个不带有Activity用户接口的从网络上获取数据的Service。
Content providers
Content provider管理一个共享的应用程序数据集，可以在文件系统（一个SQLite数据库、在网络上、或者其他的应用程序能够访问的本地的持久化的存储介质）中保存数据，通过content provider，其他的应用程序能够查询或编辑（如果content provider允许）数据。例如，Android系统提供了一个管理用户通讯录的content provider。这样，任何带有适当授权的应用程序都能够查询由content provider读/写的数据。
Content provider也可用于读写应用程序的私有数据而不是共享，例如Note Pad程序就是用一个content provider来保存注释。
Content provider是做为ContentProvider的一个子类来实现的，并且必须实现一组标准的使其他应用程序能够执行事务的API。
Broadcast receivers(广播接收器)
Broadcast receivers是一个响应全系统广播通知的组件。系统有很多广播源，例如屏幕关闭的一个广播通知、电池电量不足通知、抓图通知等。应用程序也能启动广播，例如让其他的应用程序知道某些数据已经下载到设备上，并且应用可以有效使用。虽然Broadcast receivers不显示用户接口，但是他们可以创建状态栏通知，提醒用户广播事件发生了。更常见的是，Broadcast receivers只是作为其他组件的一个网关，并且做很少的工作。例如，它可以启动一个执行某些基于事件来工作的服务。
Broadcast receiver是做为BroadcastReceiver的一个子类来实现的，并且每个广播作为一个Intent对象来分发。
Android系统设计独特一面是任何应用程序都能够启动另外应用程序的组件。例如，如果想要用户使用相机设备拍照，就有可能在一个应用程序中拍照而在另外一个应用程序中使用照片，而不需要在自己的应用程序中开发一个用于拍照的Activity。你不需要合并或事件联接来自相机应用的代码，而是简单启动照相机应用中用于拍照的Activity。当拍照完成，这个事件就返回到你的应用程序以便你能够使用照片。对于用户来说，照相机应用程序就好像你的应用的一部分。
系统启动一个组件时，它会启动那个应用的进程（如果应用未运行），并且初始化组件需要的类。例如，如果你的应用程序启动照相机应用中用于拍照的Activity，这个Activity运行在属于照相机应用的进程中，而不是你自己的进程中。因此，跟大多数其他系统不一样，Android应用程序没有一个单独的进入点（例如，没有main()方法）。
由于系统在一个独立的限制访问其他应用文件的进程中运行每个应用程序，所以应用程序不能直接激活来自其他应用程序的组件。但是，Android系统可以做到，因此要激活另一个应用程序中的一个组件，就必须发一个消息给系统，指定打算启动的特定的组件，然后系统为你激活这个组件。
激活组件
四种类型组件中的三种（Activities、Services、Broadcast receivers）是通过被叫做Intent的异步消息激活的。Intents在运行时绑定彼此独立的组件（可以把它想象成一个来自其他组件的请求一个动作信使），而不关注组件是属于应用自己还是其他的应用程序。
一个Intent就是一个Intent对象，它定义了一个消息，既可以激活指定的组件也可以激活指定的组件类型，一个Intent既可以是明确的也可以是隐含的。
对于Activities和Services，一个Intent定义了要执行的动作（例如：浏览或发送等事情），并且可以指定数据位置（对于正在启动的组件可能需要了解这些信息）。例如，一个Intent可能传达一个请求，要一个Activity显示一张图片或打开一个Web网页。在某些场合，还可以启动一个Activity来接收一个结果，这个Activity也返回Intent中的结果（例如：你可以发出一个Intent，让用户选择一个个人的联系方式，并且要它返回给你，返回的Intent包括一个指向选择的联系方式的位置）。
对于广播接收器，Intent简单的定义了广播的通知（例如，一个指示设备电量不足的广播，只包含了一个已知行为的字符串：电池电量不足.）。
另一个组件类型—Content Provider不是用Intents来激活的，它是在来自一个ContentResolver对象请求目标时被激活。内容解析器使用Content Provider处理所有的直接事务，以便组件不必在用Content Provider来执行事务，而是调用ContentResolver对象上的方法。这样就在内容提供者和组件请求信息之间形成了一个抽象层。
每种类型组件都有独立的方法来进行激活：
1. 通过传递一个Intent给startActivity()或startActivityForResult()（需要Activity返回一个结果时调用这个方法）方法能够启动一个Activity（或者让这个Activity做一些新的事情。）
2. 通过传递一个Intent给startService()方法来启动一个Service（或者给一个运行的Service发送新的指令），也可以通过传递一个Intent给bindService()方法绑定Service
3. 通过传递一个Intent给sendBroadcast()、sendOrderedBroadcast()、sendStickyBroadcast()这样的方法可以启动一个广播；
4. 通过调用ContentResolver上的query()方法，可以执行一个对Content Provider的查询。
关于使用Intents的更多信息，可以看目的和目的过滤器（Intents and Intent Filters）。关于激活特定组件的更多信息在下列文档中也提供了：Activities、Services、BroadcastReceiver和Content Providers。
清单文件
Android系统在启动一个应用程序组件之前，必须通过阅读应用程序的AndroidManifest.xml文件来了解组件的存在情况。应用程序必须在这个文件中声明所有的它用到的组件，这个文件必须在应用项目目录根目录。
清单文件除了声明应用程序组件之外，还做了许多其他的事情，如：
1. 标识应用程序需要的用户权限，如：互联网访问或读取用户联系人的权限等；
2. 声明应用程序需要的最小API级别，也就是要说明应用程序使用的是基于那个级别的Android API；
3. 声明应用程序使用或需要的硬件和软件的功能，例如照相机、蓝牙服务、或多点触摸；
4. 应用程序需要的API库链接（Android框架API除外），如Google地图类库。
声明组件
清单（Manifest）的主要任务是通知系统应用程序的组件构成，例如，清单文件能够像下例那样声明一个Activity：
lt;?xml version='1.0' encoding='utf-8'?gt;
lt;manifest ... gt;
lt;application android:icon='@drawable/app_icon.png' ... gt;
lt;activity android:name='com.example.project.ExampleActivity'
android:label='@string/example_label' ... gt;
lt;/activitygt;
...
lt;/applicationgt;
lt;/manifestgt;
在lt;applicationgt;元素中，android:icon属性指明了标识应用程序的一个图标。
在lt;activitygt;元素中，android:name属性指定了Activity子类的完整类名，android:label属性给Activity指定了一个用于显示给用户的字符串标签。
必须使用以下方法声明所有的应用程序组件：
1. lt;activitygt;元素用于声明Activities
2. lt;servicegt;元素用于声明Services
3. lt;receivergt;元素用于声明Broadcast receivers
4. lt;providergt;元素用于声明 Content Providers
在 源代码中包含的Activities、Services、和Content Providers没有在清单文件中声明，对系统就是不可见的，所以就不能运行。但是Broadcast Receivers既可以在清单文件中声明也可以在代码中动态的创建（如BroadcastReceiver对象），然后通过调用registerReceiver()方法在系统中注册。
关于应用程序的清单文件结构的更多内容，可以查看The AndroidManifest.xml File文档。
声明组件的能力
像
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[146755]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
