安卓的机制与安全性毕业论文外文翻译

《安卓的机制与安全性毕业论文外文翻译》由会员分享，可在线阅读，更多相关《安卓的机制与安全性毕业论文外文翻译（12页珍藏版）》请在毕设资料网上搜索。

1、中文 5210 字 附录 A 外文翻译 -原文部分 Android security mechanism The next generation of open operating systems wont be on desktops or mainframes but on the small mobile devices we carry every day. The openness of these new environments will lead to new applications and markets and will enable greater integratio

2、n with existing online services. However, as the importance of the data and services our cell phones support increases, so too do the opportunities for vulnerability. Its essential that this next generation of platforms provides a comprehensive and usable security infrastructure. Developed by the Op

3、en Handset Alliance (visibly led by Google), Android is a widely anticipated open source operating system for mobile devices that provides a base operating system, an application middleware layer, a Java software development kit (SDK), and a collection of system applications. Although the Android SD

4、K has been available since late 2007, the first publicly available Android ready “G1” phone debuted in late October 2008. Since then, Androids growth has been phenomenal: T-Mobiles G1 manufacturer HTC estimates shipment volumes of more than 1 million phones by the end of 2008, and industry insiders

5、expect public adoption to increase steeply in 2009. Many other cell phone providers have either promised or plan to support it in the near future. A large community of developers has organized around Android, and many new products and applications are now available for it. One of Androids chief sell

6、ing points is that it lets developers seamlessly extend online services to phones. The most visible example of this feature is, unsurprisingly, the tight integration of Googles Gmail, Calendar, and Contacts Web applications with system utilities. Android users simply supply a username and password,

7、and their phones automatically synchronize with Google services. Other vendors are rapidly adapting their existing instant messaging, social networks, and gaming services to Android, and many enterprises are looking for ways to integrate their own internal operations (such as inventory management, p

8、urchasing, receiving, and so forth) into it as well. Traditional desktop and server operating systems have struggled to securely integrate such personal and business applications and services on a single platform. Although doing so on a mobile platform such as Android remains nontrivial, many resear

9、chers hope it provides a clean slate devoid of the complications that legacy software can cause. Android doesnt officially support applications developed for other platforms: applications execute on top of a Java middleware layer running on an embedded Linux kernel, so developers wishing to port the

10、ir application to Android must use its custom user interface environment. Additionally, Android restricts application interaction to its special APIs by running each application as its own user identity. Although this controlled interaction has several beneficial security features, our experiences d

11、eveloping Android applications have revealed that designing secure applications isnt always straightforward. Android uses a simple permission label assignment model to restrict access to resources and other applications, but for reasons of necessity and convenience, its designers have added several

12、potentially confusing refinements as the system has evolved. This article attempts to unmask the complexity of Android security and note some possible development pitfalls that occur when defining an applications security. We conclude by attempting to draw some lessons and identify opportunities for

13、 future enhancements that should aid in clarity and correctness. Android Applications The Android application framework forces a structure on developers. It doesnt have a main()function or single entry point for executioninstead, developers must design applications in terms of components. Example Ap

14、plication We developed a pair of applications to help describe how Android applications operate. Interested readers can download the source code from our Web site (http:/siis.cse.psu. edu/android_sec_tutorial.html). Lets consider a location-sensitive social networking application for mobile phones i

15、n which users can discover their friends locations. We split the functionality into two applications: one for tracking friends and one for viewing them. As Figure 1 shows, the FriendTracker application consists of components specific to tracking friend locations (for example, via a Web service), sto

16、ring geographic coordinates, and sharing those coordinates with other applications. The user then uses the FriendViewer application to retrieve the stored geographic coordinates and view friends on a map. Both applications contain multiple components for performing their respective tasks； the compon

17、ents themselves are classified by their component types. An Android developer chooses from predefined component types depending on the components purpose (such as interfacing with a user or storing data). Component Types Android defines four component types: Activity components define an application

18、s user interface. Typically, an application developer defines one activity per “screen.” Activities start each other, possibly passing and returning values. Only one activity on the system has keyboard and processing focus at a time； all others are suspended. Service components perform background pr

19、ocessing. When an activity needs to perform some operation that must continue after the user interface disappears (such as download a file or play music), it commonly starts a service specifically designed for that action. The developer can also use services as application-specific daemons, possibly

20、 starting on boot. Services often define an interface for Remote Procedure Call (RPC) that other system components can use to send commands and retrieve data, as well as register callbacks. Content provider components store and share data using a relational database interface. Each content provider

21、has an associated “authority” describing the content it contains. Other components use the authority name as a handle to perform SQL queries (such as SELECT, INSERT, or DELETE) to read and write content. Although content providers typically store values in database records, data retrieval is impleme

22、ntation specificfor example, files are also shared through content provider interfaces. Broadcast receiver components act as mailboxes for messages from other applications. Commonly, application code broadcasts messages to an implicit destination. Broadcast receivers thus subscribe to such destinati

23、ons to receive the messages sent to it. Application code can also address a broadcast receiver explicitly by including the namespace assigned to its containing application. Figure 1 shows the FriendTracker and FriendViewer applications containing the different component types. The developer specifie

24、s components using a manifest file. There are no restrictions on the number of components an application defines for each type, but as a convention, one component has the same name as the application. Frequently, this is an activity, as in the FriendViewer application. This activity usually indicate

25、s the primary activity that the system application launcher uses to start the user interface； however, the specific activity chosen on launch is marked by meta information in the manifest. In the FriendTracker application, for example, the FriendTrackerControl activity is marked as the main user int

26、erface entry point. In this case, we reserved the name “FriendTracker” for the service component performing the core application logic. The FriendTracker application contains each of the four component types. The FriendTracker service polls an external service to discover friends locations. In our e

27、xample code, we generate locations randomly, but extending the component to interface with a Web service is straightforward. The FriendProvider content provider maintains the most recent geographic coordinates for friends, the FriendTracker Control activity defines a user interface for starting and

28、stopping the tracking functionality, and the BootReceiver broadcast receiver obtains a notification from the system once it boots (the application uses this to automatically start the FriendTracker service). The FriendViewer application is primarily concerned with showing information about friends l

29、ocations. The FriendViewer activity lists all friends and their geographic coordinates, and the FriendMap activity displays them on a map. The FriendReceiver broadcast receiver waits for FriendTrackerControl activity, for instance, can start and stop the FriendTracker service that runs in the backgr

30、ound. The bind action establishes a connection between components, allowing the initiator to execute RPCs defined by the service. In our example, FriendTracker binds to the location manager in the system server. Once bound, FriendTracker invokes methods to register a callback that provides updates o

31、n the phones location. Note that if a service is currently bound, an explicit “stop” action wont terminate the service until all bound connections are released. Broadcast receiver and content provider components have unique forms of interaction. ICC targeted at a broadcast receiver occurs as an intent sent (broadcast) either explicitly to the component or, more commonly, to an action string the component subscribes to. For example, FriendReceiver subscribes to the developer-defined “FRIEND_NEAR” action string. FriendTracker broadcasts an intent to this action string when it