【文章內(nèi)容簡介】 ns (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 ofcially support applications eloped 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 benefcial security features, our experiences developing Android applications have revealed that designing secure forward. 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 refnements as the system has article attempts to unmask the plexity of Android security and note some possible development pitfalls that occur when defning 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. 11 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 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 specifc 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 performing their respective tasks。 the ponents themselves are classifed by their ponent types. An Android developer chooses from predefned ponent types depending on the ponent’s purpose (such as interfacing with a user or storing data). Component Types Android defnes four ponent types: Activity? ponents defne an application’s user interface. Typically, an application developer defnes one activity per “screen.” Activities start each other, possibly passing and returning values. Only one activity on the system has keyboard and ocessing focus at a time。 all others are suspended. Service ponents perform background processing. When an activity needs to perform some operation that must continue after the user interface disappears (such as download a fle or 12 play music), it monly starts a service specifcally designed for that action. The developer can also use services as applicationspecifc daemons, possibly starting on boot. Services often define an interface for Remote Procedure Call (RPC) that other system ponents can use to send mands and retrieve data, as well as register callbacks. Content provider ? ponents store and share data using a relational database interface. Each content provider has an associated “authority” describing the content it contains. Other ponents 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 implementationspecifc— for example, fles are also shared through content provider interfaces. Broadcast receiver? ponents act as mailboxes for messages from other applications. Commonly, application code broadcasts messages to an implicit destination. Broadcast receivers thus subscribe to such destinations 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