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 application#39;s 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 application#39;s components need to be executed, then shuts down the process when it#39;s 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:
- It#39;s possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each other#39;s 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 user#39;s 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 application#39;s 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 user#39;s contact information. As such, any application with the proper permissions can query part of the content provider (such as ContactsContract.Data) to read and write information about a particular person.
Content providers are also useful for reading and writing data that is private to your application and not shared. For example, the Note Pad sample application uses a content provider to save notes.
A content provi
全文共22794字，剩余内容已隐藏，支付完成后下载完整资料
Android应用基础
Android应用程序是采用Java编程语言编写的，所有的Java代码和相关的资源文件被Android SDK打包成一个后缀为apk的Android包。一个APK包里所有的代码都被看做一个程序,并且用来安装应用程序到基于Android系统的移动设备上。
一旦安装到一个设备上，每一个Android应用程序都在自己的安全沙盒里（虚拟机）里单独存活：
1）Android操作系统是一个多用户的Linux系统，在这个操作系统中每个程序都是一个单独的用户。
2）默认情况下，系统为每个应用程序都会分配一个唯一的Linux用户ID（这个ID只能被系统使用，对于应用程序是未知的），系统为一个应用程序的所有文件设置权限，只有那些被分配了使用权限的程序才可以访问到那些相应的文件。
3）每个进程都拥有自己的虚拟机，所以一个应用程序的代码运行在和其他应用程序互相隔离的空间里。
4）默认情况下，每一个进程都会运行在他自己的Linux进程下，应用程序的任何一段代码（比如Activity）需要被执行时，Android都会启动这个进程，并且会在应用不需要，或者当系统需要为其他进程恢复内存的时候时候关闭这个进程。
基于以上这些特点，Android系统实现了最少权限原则，在通常情况下，每个应用程序默认只能访问他需要使用到的部分，这样创建了一个非常安全的机制，在这个机制下，一个应用程序不能访问系统没有给予权限的其他部分。
然而，这里有很多方法使得一个应用程序可以共享数据给其他应用，并且可以使得应用程序可以访问系统的服务：
1）为了让不同应用可以互相访问彼此的文件，系统可以安排两个程序共享一个Linux用户ID，为了节省系统资源，拥有相同用户ID的应用程序运行在相同的Linux进程，共享相同的虚拟机(应用程序也必须使用相同的证书)，这样他们就可以互相看到对方的文件。
2）一个应用程序可以请求获取权限访问设备的数据的权限，例如用户的通讯录，短信，扩充存储，摄像头，蓝牙和其他设备。所有的应用程序的应用权限都必须在安装的时候由用户给予授权。
上面的这些描述覆盖了一个Android应用如何在系统中存在的基础知识，这个文档的剩余部分会为你介绍:
1）定义我们应用程序的核心框架组件。
2）我们在应用程序中声明组件和需要的设备特征的manifest文件。
3）独立于应用代码，并允许我们的应用程序优雅地优化其行为以适用于多种设备配置的资源文件。
应用组件(Application Components)
应用程序的组件是一个Android应用程序的必备的基本构件模块。每一个组件是不同的基本点，系统通过他们可以进入到你的应用程序中。不是所有的组件都有用户的实际入口点，其中一些是相互依赖于彼此的，但是每一个都作为自己的实体存在并且同时也扮演了一个特定的角色，每一个组件都是一个有助于定义我们应用程序整体行为的唯一的不可或缺的构件模块。
Android系统支持4种不同类别的应用程序组件，每一个类型的组件都有不同的目的并且有着不同定义了组件是如何被创建与销毁的的生命周期。
四种APP组件类型如下：
（1）活动（Activities）
活动提供了一个用户接口的单一界面，例如：一个邮件应用程序可以提供一个活动用来显示新邮件的列表，另一个活动可以用来写一封新邮件，同时还有一个活动用来读取邮件。虽然这些活动共同工作在一个邮件应用程序中以形成一个有结合力的用户体验，但是每一个活动都是相互独立的。因此，一个不同的应用程序也可以启动这些活动中的任何一个（只要邮件应用程序允许它这么做）。例如，一个拍照应用程序可以启动一个邮件程序中的活动用来编写一封邮件，以便用户可以分享一张照片。
一个activity作为Activity的子类来实现，你可以通过开发者指南网站的Activities部分来学习更多关于activity的功能。
（2）服务（Service）
服务是一个在后台长时间不间断运作或者为远程进程进行工作的组件。服务不提供用户界面。例如：当用户在使用另一个应用程序时，一个服务可以在后台播放音乐、读取网络数据而不妨碍用户和另一个活动进行交互。另一个组件，例如活动，可以启动服务并且让他开始运作，或者为了和服务进行交互而绑定它。
一个service是作为Service的子类来实现，你可以通过开发者指南网站的Services部分来学习service的功能。
（3）内容提供器（Content providers）
一个内容提供器管理一组共享的应用程序数据，我们可以保存这些数据到文件系统、SQLite数据库、web，或是保存在我们的应用程序能够访问的任何其他永久保存的位置。通过内容提供器，其他应用程序能够查询或甚至是修改这些共享的数据(如果内容提供器允许这么操作)。比如，Android系统提供一个内容提供器来管理用户联系人信息，因此，有适当权限的任何应用程序能够查询内容提供器的一部分(比如ContactsContract.Data)来读和写一个特定用于的信息。
内容提供器也有助于读写我们应用程序的私有数据(不共享)，比如记事本示例应用程序使用一个内容提供器来保存笔记。
一个内容提供器作为Content Provider的子类来实现，并且必须实现一组标准的API，这样可使其他APP执行事务。
（4）广播接收器（Broadcast receiver）
广播接收器是一个响应整个系统的广播通知的组件。很多广播产生于系统，例如一个广播通知屏幕已经锁住、电量十分低、或者一张图片被捕获，应用程序也可以初始化广播，例如，让其他应用程序知道一些数据已经开始下载到设备上并且可以为他们所使用，尽管广播接收器没有显示用户界面，他们可以在广播事件发生时创建一个状态栏通知用来警示用户。然而更通常的是，广播接受者仅仅是一个通道来通知其他组件并且做了非常少量的工作。例如，他可能基于一些事件来初始化某些服务用以执行一些工作。
一个广播接收器作为广播接收器的子类来实现，每个广播以Intent对象的形式被分发出去。你可以在Broadcast Receiver类中查找更多信息。
Android系统设计的一个独特的一面是任何应用程序能够启动另一个应用程序的组件，比如，如果我们想要用户使用带摄像头的设备来拍照，可能已经有另一个应用程序实现了拍照功能，并且我们的应用程序能够使用这个拍照功能，而不需要自己来开发一个活动来实现拍照功能，而且我们也不需要包含或是链接这个拍照程序。相反，我们能够简单的启动拍照应用程序的活动来拍照。当拍照完成，照片甚至能够返回到我们的应用程序中。对于用户来说，拍照功能就像是我们的应用程序的实际的一部分一样。
当系统启动一个组件，如果这个组件所在的程序之前没有运行，那么系统就开始这个应用程序的进程，并且实例化这个组件所需要的类。比如，如果我们的应用程序启动拍照应用程序的拍照功能对应的活动，这个活动运行在拍照应用程序的进程，而不是我们的应用程序的进程中。所以，不像其他大部分系统的应用程序，Android系统的应用程序没有一个单独入口点(比如没有main函数)。
因为系统每个应用程序运行在自己独立的进程中，并且应用程序中的文件都有自己的权限来限制访问其他应用程序。我们的应用程序不能直接激活其他应用程序的组件，但是Android系统可以，为了激活其他应用程序的组件，我们必须发送一个说明了激活一个特定组件的意图的消息给系统，这样系统就可以为你激活这个组件。
激活组件(Activating Components)
活动、服务和广播接收器这Android系统4种组件类型中的3种是由一种名为intent的异步消息来激活的，这些intents在运行时，把属于我们的应用程序或是其他应用程序的单独组件绑定在一起，我们可以把intent看做是需要其他组件激活的消息。
一个Intent是以一个Intent对象的形式创建，它定义了一条消息来激活一个指定的组件或者一类特定的组件，一个Intent可以被显示指定或者隐式指定。
对于活动和服务来说，一个intent定义了要执行的操作(比如要view或是send一些内容) 和指定要操作的数据URI(除此之外，开始的组件也需要知道)。例如，一个intent可能为一个活动发送显示一张图片或者打开一个网页。在一些情况下，你可以启动一个活动来获取返回的结果，在这种情况下，这个活动可以返回结果到Intent中(比如，我们可以发出一个intent让用户选择一个个人联系人名和让它返回给我们，这个返回的intent包含已选中的contact的URI)。
对于广播接收器来说，Intent简单的定义了要广播的通知(比如，一个指示设备电池低电量的广播，只是包含了一个已知动作的字符串“低电量”)。
对于最后一个组件类型，内容提供者并不是由Intent来激活，而是由一个指定请求目标的Content Resolver所激活。这个内容解析器处理所有与内容提供者的直接事务。所以执行提供者事务的内容提供者不需要intent，而是调用Content Resolver对象上的方法来激活。这样可在内容提供者和这个组件请求的信息保持在一个抽象层(为了安全)。
每种类型的组件有自己的办法来激活相应的组件：
1）你可以通过传递一个Intent给startActivity方法或者startActivtiyForRespult方法（如果我们需要这个活动返回结果）来启动一个活动 (或是给它一些新的要做的事情)。
2）你可以通过传递一个Intent给startSevice方法来启动一个service(或是给一个新指令给正在运行的serice)，或是我们可以传递一个Intent给bindService方法来绑定一个service。
3）你可以通过传递一个intent给sendBroadcast方法、sendOrderedBroadcast方法或是sendStickyBroadcast方法这些方法来发起一个广播。
4）我们可以通关过调用一个ContentResolver对象的query()来查询一个内容提供者。
Manifest文件（The Manifest File）
在Android系统启动一个应用程序组件之前，系统必须通过读取应用程序的AndroidManifest.xml文件来知道该应用程序需要使用哪些组件，你的程序必须把所有需要的组件声明在那个文件里面，并且该文件必须在应用程序工程的根目录下。除了声明应用程序的组件之外，manifest文件还做了下面一些事情：
1）确定APP需要的任何用户权限，比如确认程序访问网络，读取用户通讯录的权限等
2）基于应用程序所使用的API来声明运行这个APP需要的最低API版本。
3）声明APP需要的硬件和软件特征，比如摄像头、蓝牙服务或是一个多点触屏。
4）申明该程序需要连接的API库(不是Android framework的API)，比如Google Maps库。
声明组件（declaring components）
Manifest文件的首要任务是通知系统关于应用程序中使用的组件，比如一个manifest文件能像下面一样声明活动：
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属性指向了标示这个应用程序的icon资源。
在lt;activitygt;元素中，android:name属性指定了Activity子类的完整类别名称，android:label属性指定了标示activity对于用户可见的label。
我们必须用下面的方式来声明应用程序的所有组件：
(1)lt;activitygt;元素声明活动。
(2)lt;servicegt;元素声明服务。
(3)lt;receivergt;元素声明广播接收器。
(4)lt;providergt;元素声明内容提供器。
我们如果在程序中包含了活动、服务和内容提供器，但没有在manifest文件中声明，那么这些组件对系统不可见，因此，这些组件不能运行。但是，广播接收器不仅可以在manifest文件中声明，也可以在代码中动态创建(作为Broadcast Receiver对象)，并通过调用registerReceiver方法在系统中注册。
全文共8230字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[11756]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
