安卓的機(jī)制與安全性畢業(yè)論文外文翻譯

1、<p><b>　　中文5210字</b></p><p>　　附錄A 外文翻譯-原文部分</p><p>　　Android security mechanism </p><p>　　The next generation of open operating 

2、systems won’t be on desktops or mainframes but on the small mobile devices we carry every day. The openness of these

3、0;new environments will lead to new applications and markets and will enable greater integration with existing online services. Ho

4、wever, as the importance of the data and services our cell phones support increases, so too do the opportunities for vul

5、nerability. It’s essential that this next generation of platforms provides a comprehensive and us</p><p>　　Developed by the Ope

6、n Handset Alliance (visibly led by Google), Android is a widely anticipated open source operating system for mobile devices t

7、hat provides a base operating system, an application middleware layer, a Java software development kit (SDK), and a collection

8、0;of system applications. Although the Android SDK has been available since late 2007, the first publicly available Android ready&

9、#160;“G1” phone debuted in late October 2008. Since then, Android’s growth has been phenomenal: T-Mobile’</p><p>　　A large comm

10、unity of developers has organized around Android, and many new products and applications are now available for it. One of

11、0;Android’s chief selling points is that it lets developers seamlessly extend online services to phones. The most visible example&

12、#160;of this feature is, unsurprisingly, the tight integration of Google’s Gmail, Calendar, and Contacts Web applications with system&#

13、160;utilities. Android users simply supply a username and password, and their phones automatically synchronize wi</p><p>　　Traditional

14、60;desktop and server operating systems have struggled to securely integrate such personal and business applications and services on

15、60;a single platform. Although doing so on a mobile platform such as Android remains nontrivial, many researchers hope it pro

16、vides a clean slate devoid of the complications that legacy software can cause. </p><p>　　Android doesn’t officially support

17、60;applications developed for other platforms: applications execute on top of a Java middleware layer running on an embedded Linux

18、 kernel, so developers wishing to port their application to Android must use its custom user interface environment.   &l

19、t;/p><p>　　Additionally, Android restricts application interaction to its special APIs by running each application as its own user

20、 identity. Although this controlled interaction has several beneficial security features, our experiences developing Android applications ha

21、ve revealed that designing secure applications isn’t always straightforward. Android uses a simple permission label assignment model to

22、 restrict access to resources and other applications, but for reasons of necessity and convenience, its de</p><p>　　This a

23、rticle attempts to unmask the complexity of Android security and note some possible development pitfalls that occur when defining&

24、#160;an application’s security. We conclude by attempting to draw some lessons and identify opportunities for future enhancements that&

25、#160;should aid in clarity and correctness. </p><p>　　Android Applications </p><p>　　The Android application framework forces a&#

26、160;structure on developers. It doesn’t have a  main()function or single entry point for execution—instead, developers must design 

27、;applications in terms of components.  </p><p>　　Example Application </p><p>　　We developed a pair of applications to h

28、elp describe how Android applications operate. Interested readers can download the source code from our Web site (http://siis.cse.psu.&

29、#160;edu/android_sec_tutorial.html).  </p><p>　　Let’s consider a location-sensitive social networking application for mobile phones in which&#

30、160;users can discover their friends’ locations. We split the functionality into two applications: one for tracking friends and on

31、e for viewing them. As Figure 1 shows, the FriendTracker application consists of components specific to tracking friend locations&

32、#160;(for example, via a Web service), storing geographic coordinates, and sharing those coordinates with other applications. The user&

33、#160;then uses the FriendV</p><p>　　Both applications contain multiple components for performing their respective tasks; the components&#

34、160;themselves are classified by their  component types. An Android developer chooses from predefined component types depending on 

35、;the component’s purpose (such as interfacing with a user or storing data).  </p><p>　　Component Types </p><p>　　Androi

36、d defines four component types: </p><p>　　? Activity components define an application’s user interface. Typically, an application

37、60;developer defines one activity per “screen.” Activities start each other, possibly passing and returning values. Only one activity&#

38、160;on the system has keyboard and processing focus at a time; all others are suspended. </p><p>　　? Service components

39、60;perform background processing. When an activity needs to perform some operation that must continue after the user interface dis

40、appears (such as download a file or play music), it commonly starts a service specifically designed for that action.  &l

41、t;/p><p>　　The developer can also use services as application-specific daemons, possibly starting on boot. </p><p>　　Services o

42、ften define an interface for Remote Procedure Call (RPC) that other system components can use to send commands and retrieve&#

43、160;data, as well as register callbacks.</p><p>　　? Content provider components store and share data using a relational databas

44、e interface. Each content provider has an associated “authority” describing the content it contains. Other components use the auth

45、ority name as a handle to perform SQL queries (such as SELECT, INSERT, or DELETE) to read and write content. Although

46、60;content providers typically store values in database records, data retrieval is implementation specific—for example, files are also 

47、shared through content provider interfaces.</p><p>　　? Broadcast receiver components act as mailboxes for messages from other applic

48、ations. Commonly, application code broadcasts messages to an implicit destination. Broadcast receivers thus subscribe to such destinations&#

49、160;to receive the messages sent to it. Application code can also address a broadcast receiver explicitly by including the na

50、mespace assigned to its containing application.  </p><p>　　Figure 1 shows the FriendTracker and FriendViewer applications containing

51、 the different component types. The developer specifies components using a manifest file. There are no restrictions on the nu

52、mber of components an application defines for each type, but as a convention, one component has the same name as the

53、0;application. Frequently, this is an activity, as in the FriendViewer application. This activity usually indicates the primary activit

54、y that the system application launcher uses to start</p><p>　　In the FriendTracker application, for example, the FriendTrackerContro

55、l activity is marked as the  main user interface entry point. In this case, we reserved the name “FriendTracker” for

56、0;the service component performing the core application logic.  </p><p>　　The FriendTracker application contains each of the fo

57、ur component types. The FriendTracker service polls an external service to discover friends’ locations. In our example code, we

58、60;generate locations randomly, but extending the component to interface with a Web service is straightforward. The FriendProvider cont

59、ent provider maintains the most recent geographic coordinates for friends, the FriendTracker Control activity defines a user interface&

60、#160;for starting and stopping the tracking functionality</p><p>　　The FriendViewer application is primarily concerned with showing infor

61、mation about friends’ locations. The FriendViewer activity lists all friends and their geographic coordinates, and the FriendMap activi

62、ty displays them on a map. The FriendReceiver broadcast receiver waits for</p><p>　　FriendTrackerControl activity, for instance, can

63、 start and stop the FriendTracker service that runs in the background. The bind action establishes a connection between compo

64、nents, allowing the initiator to execute RPCs defined by the service. In our example, FriendTracker binds to the location man

65、ager in the system server. Once bound, FriendTracker invokes methods to register a callback that provides updates on the phon

66、e’s location. Note that if a service is currently bound, an explicit “stop” a</p><p>　　Broadcast receiver and content prov

67、ider components have unique forms of interaction. ICC targeted at a broadcast receiver occurs as an intent sent (broadcast) e

68、ither explicitly to the component or, more commonly, to an action string the component subscribes to. For example, FriendReceiver&

69、#160;subscribes to the developer-defined “FRIEND_NEAR” action string. FriendTracker broadcasts an intent to this action string when it 

70、determines that the phone is near a friend; the system then starts FriendReceive</p><p>　　Content providers don’t use intents—r

71、ather, they’re addressed via an authority string embedded in a special content URI of the form c o n t e n t&#

72、160;: / / < a u t h o r i t y > /<table>/[<id>]. H e r e , <table>indicates a table

73、60;in the content provider, and <id> optionally specifies a record in that table. Components use this URI to perform a&

74、#160;SQL query on a content provider, optionally including WHERE conditions via the query API.  </p><p>　　Security Enforcement&

75、#160;</p><p>　　As Figure 3 shows, Android protects applications and data through a combination of two enforcement mechanisms, o

76、ne at the system level and the other at the ICC level. ICC mediation defines the core security framework and is thi

77、s article’s focus, but it builds on the guarantees provided by the underlying Linux system.  </p><p>　　In the general

78、 case, each application runs as a unique user identity, which lets Android limit the potential damage of programming flaws.&#

79、160;For example, the Web browser vulnerability discovered recently after the official release of T-Mobile G1 phones only affected 

80、the Web browser itself (http://securityevaluators.com/content/case-studies/android/index.jsp). Because of this design choice, the exploit couldn’t affect&#

81、160;other applications or the system. A similar vulnerability in Apple’s iPhone gave w</p><p>　　ICC isn’t limited by user 

82、and process boundaries. In fact, all ICC occurs via an I/O control command on a special device node,  /dev/binder. Becau

83、se the file must be world readable and </p><p>　　writable for proper operation, the Linux system has no way of m

84、ediating ICC. Although user separation is straightforward and easily understood, controlling ICC is much more subtle and warrants 

85、careful consideration.  </p><p>　　As the central point of security enforcement, the Android middleware mediates all ICC establi

86、shment by reasoning about labels assigned to applications and components. A reference monitor1 provides mandatory access control (MAC)&

87、#160;enforcement of how applications access components. In its simplest form, access to each component is restricted by assigning 

88、it an access permission label; this text string need not be unique. Developers assign applications collections of permission label

89、s. When a compone</p><p>　　The developer assigns permission labels via the XML manifest file that accompanies every application

90、 package. In doing so, the developer defines the application’s security policy—that is, assigning permission labels to an applicat

91、ion specifies its protection domain, whereas assigning permissions to the components in an application specifies an access policy 

92、to protect its resources. Because Android’s policy enforcement is mandatory, as opposed to discretionary, all permission labels are

93、0;set at i</p><p>　　Security Refinements </p><p>　　Android’s security framework is based on the label-oriented ICC mediation 

94、;described thus far, but our description is incomplete. Partially out of necessity and partially for convenience, the Google devel

95、opers who designed Android incorporated several refinements to the basic security model, some of which have subtle side effects

96、60;and make its overall security difficult to understand.   </p><p>　　Public vs. Private Components </p><p>　　Applications&#

97、160;often contain components that another application should never access—for example, an activity designed to return a user-entered pa

98、ssword could be started maliciously. Instead of defining an access permission, the developer could make a component private by

99、0;either explicitly setting the exported attribute to false in the manifest file or letting Android infer if the component sh

100、ould be private from other attributes in its manifest definition. </p><p>　　Private components simplify security specification. By&#

101、160;making a component private, the developer doesn’t need to worry which permission label to assign it or how another applic

102、ation might acquire that label. Any application can access components that aren’t explicitly assigned an access </p><p>　　permi

103、ssion, so the addition of private components and inference rules (introduced in the v0.9r1 SDK release, August 2008) significantly

104、 reduces the attack surface for many applications. However, the developer must be careful when allowing Android to determine 

105、if a component is private. Security-aware developers should always explicitly define the exported attribute for components intended to&

106、#160;be private.  </p><p>　　Implicitly Open Components </p><p>　　Developers frequently define intent filters on activities to

107、0;indicate that they can handle certain types of action/data combinations. Recall the example of how the system finds an imag

108、e viewer when an intent specifying the VIEW action and an image reference is passed to the “start activity” API. In 

109、;this case, the caller can’t know beforehand (much less at development time) what access permission is required. The developer

110、0;of the target activity can permit such functionality by not  assigning  an</p><p>　　Although this default policy specifi

111、cation enables functionality and ease of development, it can lead to poor security practices and is contrary to Saltzer and&#

112、160;Schroeder’s principle of fail-safe defaults.4Referring back to our example FriendViewer application, if the FriendReceiver broadcast receiver

113、 isn’t assigned an access permission, any unprivileged installed application can forge a  FRIEND_NEAR message, which represents a&

114、#160;significant security concern for applications making decisions based </p><p>　　附錄B 外文翻譯-譯文部分</p><p><b>　　安卓的機(jī)制與安全性</b></p><p&g

115、t;　　下一代開放式操作系統(tǒng)不會(huì)是在電腦或大型主機(jī)上而是在我們可以每天攜帶的小手機(jī)上。這些新環(huán)境的開放性會(huì)帶來新的應(yīng)用和市場，同時(shí)會(huì)促進(jìn)現(xiàn)存網(wǎng)絡(luò)設(shè)備的更大程度集成。但是，在我們手機(jī)所能支持的設(shè)備和數(shù)據(jù)的重要性不斷提升的情況下，出現(xiàn)問題和故障的幾率也在不斷提升。所以，下一代平臺必須要能提供一個(gè)綜合且有用的安全底層架構(gòu)支撐。 </p><p>　　由手機(jī)開放聯(lián)盟（明顯由google領(lǐng)導(dǎo)的）開發(fā)的androi

116、d，是一個(gè)為手機(jī)設(shè)備制作的被廣為期待的開源式操作系統(tǒng)。他提供了一個(gè)基礎(chǔ)運(yùn)行系統(tǒng)，一個(gè)應(yīng)用中間層，一個(gè)java軟件開發(fā)包（SDK），和一個(gè)系統(tǒng)應(yīng)用的集合。盡管android SDK從2007年后期便可以使用，但是第一個(gè)真正為公共準(zhǔn)備的android G1手機(jī)在2008年底才初次登臺。從這以后，android的成長十分顯著。T-Mobile的第一代手機(jī)制造廠商HTC預(yù)估與2008年年底，手機(jī)的總銷售量會(huì)超過1百萬臺，并且

117、產(chǎn)業(yè)內(nèi)部人員期待他的使用率會(huì)在2009年陡升。許多其他的手機(jī)提供廠商也保證或計(jì)劃在不久的將來支持這個(gè)系統(tǒng)。 </p><p>　　大量的開發(fā)者圍繞android組成了開發(fā)社區(qū)，現(xiàn)在有很多新的產(chǎn)品和應(yīng)用已經(jīng)可以使用了。Android的主要賣點(diǎn)之一就是允許開發(fā)者將網(wǎng)絡(luò)設(shè)備無縫的延伸到手機(jī)上。這個(gè)功能最為顯著的一個(gè)例子，毫無疑問，就是將google的gmail，日歷和通過系統(tǒng)功能連接網(wǎng)頁應(yīng)用的緊密集成。And

118、roid用戶只需要申請一個(gè)用戶名和密碼，然后他們的手機(jī)就可以自動(dòng)的與google的服務(wù)同步。其他的供應(yīng)商也正在迅速的改變他們已有的即時(shí)通信，社交網(wǎng)絡(luò)和游戲服務(wù)以適用于android，還有許多其他的企業(yè)也正在尋找把它們自己的內(nèi)部運(yùn)行（例如存貨管理，購買，接收等等）集成進(jìn)去的方法。 </p><p>　　傳統(tǒng)的電腦和服務(wù)器運(yùn)行系統(tǒng)一直致力于解決如何安全的將私人的和公司的應(yīng)用集成到一起并且在一個(gè)平臺上服務(wù)。盡

119、管像android一樣在手機(jī)平臺上達(dá)到了這個(gè)功能是十分不平凡的，許多研究者仍希望他能提供一個(gè)沒有遺留軟件引起的并發(fā)癥的干凈的石板。Android并不官方的支持為其他平臺開發(fā)的應(yīng)用軟件：在java中間層上方執(zhí)行的應(yīng)用軟件實(shí)際是運(yùn)行在一個(gè)嵌入式的Linux內(nèi)核中，所以開發(fā)者若想將他們的應(yīng)用傳送到android系統(tǒng)，則必須使用他們定制的用戶接口環(huán)境。另外，android通過把每個(gè)應(yīng)用看做他自己的用戶認(rèn)證來運(yùn)行，從而很好的限制了應(yīng)用與他們的特殊

120、的API的交互。盡管這些交互的控制措施有一些有益的安全特性，但是我們開發(fā)android應(yīng)用的體驗(yàn)揭露了設(shè)計(jì)安全的應(yīng)用不總是簡單而直接的。Android使用一個(gè)簡單的許可證標(biāo)簽分配模型來限制對信息源和其他應(yīng)用的使用，但是由于必要性和方便性的原因，他的設(shè)計(jì)者在系統(tǒng)進(jìn)化的時(shí)候增加了幾個(gè)潛在的混亂精煉。 </p><p>　　這篇文章意圖揭開復(fù)雜的android安全性的神秘面紗并且指出一些可能發(fā)生在定義一個(gè)應(yīng)用

121、的安全性時(shí)的開發(fā)陷阱。我們通過嘗試借鑒一些經(jīng)驗(yàn)教訓(xùn)和為將來的能夠?yàn)橥该餍院驼_性提供幫助的功能改善定義機(jī)會(huì)來下結(jié)論。 </p><p>　　Android應(yīng)用 </p><p>　　Android應(yīng)用的架構(gòu)為開發(fā)者規(guī)定了一個(gè)結(jié)構(gòu)。他沒有一個(gè)主要功能或者一個(gè)單一的執(zhí)行入口——替代這些的是，開發(fā)者必須以組件的形式設(shè)計(jì)應(yīng)用程序。 </p><p&

122、gt;<b>　　樣例應(yīng)用 </b></p><p>　　我們開發(fā)了一些應(yīng)用程序來幫助描述android應(yīng)用是怎么運(yùn)行的。感興趣的讀者可以從我們的網(wǎng)站上下載這些源代碼。</p><p>　　我們來考慮一個(gè)手機(jī)上的位置敏感的社交網(wǎng)絡(luò)應(yīng)用——用戶可以用它來定位朋友的位置。我們按照功能將它分成兩個(gè)應(yīng)用：一個(gè)用來跟蹤朋友，另一個(gè)用來觀察他們。在功能一種，朋友追蹤這個(gè)

123、應(yīng)用包含了特定用于追蹤朋友位置的組件（舉個(gè)例子，通過一個(gè)網(wǎng)頁服務(wù)），儲存地理坐標(biāo)，并且與其他應(yīng)用共享這些坐標(biāo)。用戶接下來使用朋友觀察器應(yīng)用來檢索已經(jīng)</p><p>　　儲存的地理坐標(biāo)并在地圖上觀察他的朋友的位置。 </p><p>　　這兩個(gè)應(yīng)用都包含了多種用于實(shí)現(xiàn)各自功能的組件；這些組件自己是通過他們的組件類型分類的。一個(gè)android開發(fā)者從按照組件目的預(yù)定義的組件類型（例

124、如和用戶交互或者儲存數(shù)據(jù)）中選擇。 </p><p><b>　　組件類型 </b></p><p>　　Android定義了四個(gè)組件類型： </p><p>　　Activity組件被定義為一個(gè)應(yīng)用的用戶接口。具體來說，就是一個(gè)應(yīng)用程序開發(fā)者為每一個(gè)“屏幕”定義一個(gè)activity。Activity開始另一個(gè)，有

125、可能傳遞或者接受一個(gè)值。在同一時(shí)間，系統(tǒng)中只有一個(gè)activity擁有鍵盤并且運(yùn)行著焦點(diǎn)。而所有其他的都被暫停著。 </p><p>　　Service組件執(zhí)行背景運(yùn)行。當(dāng)一個(gè)activity需要執(zhí)行一些必須在用戶接口消失后仍然保持的功能（例如下載一個(gè)文件或者播放音樂）的時(shí)候，通常開始一個(gè)為這個(gè)操作特意定義的service。開發(fā)這也可以把service當(dāng)做特定應(yīng)用的守護(hù)進(jìn)程使用，很有可能在啟動(dòng)時(shí)執(zhí)行。S

126、ervice經(jīng)常為遠(yuǎn)程過程調(diào)用（RPC）定義接口，其他系統(tǒng)組件可以用RPC來發(fā)送命令并調(diào)用數(shù)據(jù)，同時(shí)緩沖回調(diào)。 </p><p>　　Content provider組件通過使用相關(guān)的數(shù)據(jù)庫接口來儲存并分享數(shù)據(jù)。每個(gè)Content provider都有一個(gè)相關(guān)的“授權(quán)”用來描述它包含的內(nèi)容。其他組件使用這個(gè)授權(quán)名作為訪問數(shù)據(jù)庫（例如選擇，插入，或者刪除）的把手，以此來讀寫內(nèi)容。經(jīng)過C

127、ontent provider在數(shù)據(jù)庫記錄中儲存值，數(shù)據(jù)的檢索是獨(dú)特的——舉個(gè)例子，文件同樣通過Content provider接口來共享。 </p><p>　　Broadcast receiver組件扮演著其他應(yīng)用消息的信箱的角色。通常來說，應(yīng)用編寫廣播消息給一個(gè)暗示的目的地。Broadcast receiver因此讓這個(gè)目的地接收送往他的消息。應(yīng)用的代碼也可

128、以為Broadcast receiver提供一個(gè)確定的地址，通過包含分配給這個(gè)應(yīng)用程序的命名空間即可。 </p><p>　　FriendTracker和FriendViewer應(yīng)用所包含的不同類型的組件。開發(fā)者用manifest文件具體化了組件。關(guān)于應(yīng)用中每個(gè)類型的組件的數(shù)量是沒有限制的，但是作為慣例，一個(gè)組件與應(yīng)用有相同的名字。常見的情況是，這里有個(gè)activity，就像在FriendVi

129、ewer應(yīng)用中。這個(gè)activity經(jīng)常指示上一個(gè)系統(tǒng)應(yīng)用運(yùn)行器用來開啟用戶接口的activity；但是，運(yùn)行器選擇的特殊的activity實(shí)在manifest中標(biāo)記為元信息的。 </p><p>　　FriendTracker應(yīng)用包含了這四種組件。FriendTracker的service輪詢一個(gè)外部的service來發(fā)現(xiàn)朋友的位置。在我們的示例代碼中，我們隨機(jī)的產(chǎn)生位置，但是將組件延伸到網(wǎng)頁服務(wù)的接

130、口上是簡單明了的。FriendProvider的content provider保存了朋友的最新地理位置坐標(biāo)，F(xiàn)riendTracker Control activity為開始和停止追蹤功能定義了一個(gè)用戶接口，而BootReceiver broadcast receiver包含了一個(gè)在系統(tǒng)啟動(dòng)的時(shí)候發(fā)送的通知（應(yīng)用通過它來自動(dòng)啟動(dòng)程序）。 </p><p&g

131、t;　　FriendViewer應(yīng)用首要功能是展示關(guān)于朋友位置的信息。FriendViewer的activity列出了所有的朋友和他們的地理位置坐標(biāo)，F(xiàn)riendMap activity將他們展示在地圖上。FriendReceiver broadcast receiver等待指示了手機(jī)本身臨近某個(gè)特定的朋友的信息，并在這種情況下將信息展示給用戶。盡管我們需要將這些組件放置在FriendTracker應(yīng)用中，

132、我們創(chuàng)建了一個(gè)分開的應(yīng)用來證明跨應(yīng)用的通信。此外，通過將追蹤和用戶接口邏輯分離，我們可以創(chuàng)建有著不同展示和特點(diǎn)的交替式接口——也就是說，許多應(yīng)用可以重新使用FriendTracker中用到的邏輯。 </p><p><b>　　組件的交互 </b></p><p>　　對于組件交互的基礎(chǔ)體制是intent，即包含了目的組件的地址和數(shù)據(jù)的消息對象。A

133、ndroid的API定義了接收intent并使用其信息來開始一個(gè)activity的方法 開始一個(gè)service的方法(startService(Intent))，和開始一個(gè)廣播消息broadcast messages的方法(sendBroadcast(Intent))。這些函數(shù)的調(diào)用告訴android架構(gòu)開始執(zhí)行目標(biāo)應(yīng)用中的代碼。這個(gè)內(nèi)部組件的通信被稱作action。簡單來說，一個(gè)intent對象定義了“intent

134、”來執(zhí)行“action”。 </p><p>　　Android的一個(gè)最為強(qiáng)大的特點(diǎn)就是由intent-addressing機(jī)制帶來的靈活性。盡管開發(fā)者可以通過使用應(yīng)用的命名空間來為特定的目標(biāo)組件尋址，但是他們也可以使用一個(gè)暗示的名稱。在后面的案例中，系統(tǒng)通過考慮一系列的已安裝應(yīng)用和用戶選擇來為一個(gè)action決定最好的組件。隱式的名字會(huì)調(diào)用一個(gè)action串，因?yàn)樗?guī)定了所需action的類型——舉例

135、來說，如果一個(gè)帶有指向了圖片文件數(shù)據(jù)的intent規(guī)定了“VIEW”action串的時(shí)候，系統(tǒng)會(huì)直接優(yōu)先跳轉(zhuǎn)到圖片viewer。開發(fā)者也使用action串來向一組broadcast receivers廣播消息。在接收端，開發(fā)者使用一個(gè)intent filter來允許一個(gè)特定的action串。Android有額外的目的地判斷規(guī)則，但是帶有可選擇的數(shù)據(jù)類型的action串是最為常見的。 </p>

136、<p>　　應(yīng)用FriendTracker和FriendViewer的組件之間的交互作用，和帶有組件的應(yīng)用被定義為基礎(chǔ)android分配的一部分。在每個(gè)案例中，一個(gè)組件啟動(dòng)與另一個(gè)的通信。簡單來說，我們調(diào)用這個(gè)內(nèi)部組件通信（ICC）。在許多時(shí)候，在Unix基礎(chǔ)系統(tǒng)中，ICC是類似于內(nèi)部進(jìn)程通信（IPC）的。對開發(fā)者而言，ICC的功能除了安全規(guī)則以外，同樣的是不考慮目標(biāo)是否在同一個(gè)應(yīng)用或者是不同的應(yīng)用中。 </p

137、><p>　　可用的ICCaction取決于目標(biāo)組件。每個(gè)類型的組件只特定支持他的類型的交互——舉個(gè)例子，當(dāng)FriendViewer啟動(dòng)了FriendMap時(shí)，activity FriendMap會(huì)出現(xiàn)在屏幕上。Service組件支持開始，停止和綁定action，所以FriendTrackerControl activity，舉例來說，可以開始或停止在后臺運(yùn)行的FriendTracker 

138、;service。綁定action為組件之間建立聯(lián)系，允許創(chuàng)始人執(zhí)行由service定義的RPCs。在我們的例子中，F(xiàn)riendTracker與系統(tǒng)service的位置管理器相綁定。一旦綁定，F(xiàn)riendTracker調(diào)用函數(shù)來登記一個(gè)提供手機(jī)位置更新的回調(diào)。需要注意的是，如果一個(gè)service現(xiàn)在是綁定的，那么一個(gè)明確的“停止”指令也不會(huì)結(jié)束service，直到綁定的連接被釋放為止。 </p><p>

139、;　　Broadcast receiver和content provider組件有獨(dú)特的交互形式。ICC把intent發(fā)送形式的broadcast receiver作為目標(biāo)，intent可以發(fā)送到一個(gè)組件，或者更為常見的，發(fā)送到一個(gè)組件同意的action串。舉個(gè)例子，F(xiàn)riendReceiver連接到開發(fā)者定義的“FRIEND_NEAR” action串。FriendTracker在發(fā)現(xiàn)手機(jī)正臨近

140、一個(gè)朋友的時(shí)候，廣播一個(gè)intent到這個(gè)action串；接下來，系統(tǒng)啟動(dòng)FriendReceiver并為用戶顯示一條信息。 </p><p>　　Content providers不使用intent，取而代之的是，他們通過嵌入在特殊授權(quán)串來尋址。這里的<table>指示了content provider中的標(biāo)簽，<id>隨意的確定了在這個(gè)標(biāo)簽中的一個(gè)記錄。組

141、件使用這個(gè)URI在content provider中執(zhí)行一個(gè)SQL數(shù)據(jù)庫的訪問，通過查詢API獲得位置條件。 </p><p><b>　　安全機(jī)制強(qiáng)制執(zhí)行 </b></p><p>　　如圖表3所示，android通過兩個(gè)強(qiáng)制機(jī)制的共同工作來保護(hù)應(yīng)用和數(shù)據(jù)，一個(gè)是在系統(tǒng)層面上，另一個(gè)在ICC層面上。ICC的仲裁定義了核心安全架構(gòu)，這也是

142、這篇文章的核心，但是他依賴于下層的Linux系統(tǒng)提供的保障。 </p><p>　　一般情況下，每個(gè)應(yīng)用都作為一個(gè)獨(dú)特的用戶標(biāo)識來運(yùn)行，這使得android限制了程序缺陷帶來的潛在傷害。舉個(gè)例子，在T-Mobile G1手機(jī)被釋放后所發(fā)現(xiàn)的網(wǎng)頁瀏覽器的脆弱性只影響網(wǎng)頁瀏覽器自己(http://securityevaluators.com/content/case-studies/android

143、/index.jsp)。因?yàn)檫@種設(shè)計(jì)的選擇，開發(fā)不會(huì)影響其他應(yīng)用或者是系統(tǒng)。一個(gè)蘋果手機(jī)中的類似脆弱性敗給了“越獄”技術(shù)，他可以運(yùn)行用戶更換一些下層系統(tǒng)的內(nèi)容，也會(huì)是基于網(wǎng)絡(luò)的開發(fā)對手利用這個(gè)瑕疵(http://securitye  valuators . com/content/case-studies/iphone/index.jsp)。 </p><p>　

144、　ICC是不被用戶和進(jìn)程邊界限制的。事實(shí)上，所有的ICC通過一個(gè)特殊的設(shè)備節(jié)點(diǎn)的I / O控制命令，/ dev /binder發(fā)生。因?yàn)槲募仨毷菍φ_的操作可讀且可寫的，Linux系統(tǒng)沒有調(diào)解ICC的方法。雖然用戶分離是非常簡單且容易理解的，控制ICC是非常微妙，且需要認(rèn)真考慮的。 </p><p>　　作為安全性強(qiáng)制執(zhí)行規(guī)則的中心點(diǎn)，在Android中間層，通

145、過推理分配給應(yīng)用程序和組件的標(biāo)簽來調(diào)解所有ICC的建立。一個(gè)的參考監(jiān)視器1提供了關(guān)于應(yīng)用程序如何訪問組件的強(qiáng)制訪問控制MAC辦法。最簡單的形式是，通過分配訪問權(quán)限的標(biāo)簽來限制對每個(gè)組件的訪問；這個(gè)文本字符串不必是唯一的。開發(fā)者分配許可標(biāo)簽的應(yīng)用集合。當(dāng)一個(gè)組件啟動(dòng)ICC時(shí)，參考監(jiān)視器檢查分配給他包含的應(yīng)用的的許可標(biāo)簽——并且如果目標(biāo)組件的訪問權(quán)限在這個(gè)集合中——并且允許ICC的創(chuàng)建執(zhí)行。如果標(biāo)簽不是在集合里，即使在同一應(yīng)用程序的組件，建

146、立也會(huì)被拒絕。圖4描述了這種邏輯。 </p><p>　　開發(fā)人員通過伴隨著每一個(gè)應(yīng)用程序包的XML manifest文件來分配權(quán)限標(biāo)簽。這樣做，使開發(fā)人員定義應(yīng)用程序的安全政策，也就是說，分配一個(gè)標(biāo)簽給指定了保護(hù)域的程序，反之，分配權(quán)限給指定一個(gè)準(zhǔn)入政策來保護(hù)它的資源的應(yīng)用程序中的組件。由于Android政策執(zhí)行是強(qiáng)制性的，與自由決定完全相反，所有的許可標(biāo)簽都是在安裝時(shí)設(shè)定的并且不能改變，直