【正文】 中文 5210 字 附錄 A 外文翻譯 原文部分 Android security mechanism The next generation of open operating systems won’t 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 integration 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. It’s essential that this next generation of platforms provides a prehensive and usable security infrastructure. Developed by the Open 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 SDK has been available since late 2021, the first publicly available Android ready “G1” phone debuted in late October 2021. Since then, Android’s growth has been phenomenal: TMobile’s G1 manufacturer HTC estimates shipment volumes of more than 1 million phones by the end of 2021, and industry insiders 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 munity of developers has anized around Android, and many new products and applications are now available for it. One of Android’s chief selling 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 Google’s Gmail, Calendar, and Contacts Web applications with system utilities. Android users simply supply a username and password, and their phones automatically synchronize with Google services. Other vendors are rapidly adapting their existing instant messaging, social works, and gaming services to Android, and many enterprises are looking for ways to integrate their own internal operations (such as inventory management, purchasing, 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 researchers hope it provides a clean slate devoid of the plications that legacy software can cause. Android doesn’t 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 their 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 developing Android applications have revealed that designing secure applications isn’t 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 potentially confusing refinements as the system has evolved. This article attempts to unmask the plexity of Android security and note some possible development pitfalls that occur when defining an application’s security. We conclude by attempting to draw some lessons and identify opportunities for future enhancements that should aid in clarity and correctness. Android Applications The Android application framework forces a structure on developers. It doesn’t have a main()function or single entry point for execution—instead, developers must design applications in terms of ponents. Example Application We developed a pair of applications to help describe how Android applications operate. Interested readers can download the source code from our Web site (. edu/). Let’s consider a locationsensitive social working application for mobile phones in 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 ponents specific to tracking friend locations (for example, via a Web service), storing 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 ponents for