【導(dǎo)讀】電設(shè)備來安裝應(yīng)用程序。默認(rèn)情況下，每個(gè)應(yīng)用程序運(yùn)行在它自己的Linux進(jìn)程。這樣一來，Android系統(tǒng)實(shí)現(xiàn)了最小特權(quán)原則，也就是說，每個(gè)應(yīng)用程序，安全的環(huán)境，使應(yīng)用程序無法訪問的，這就是它沒有給予許可制度的部分。這有可能為兩個(gè)應(yīng)用程序安排共享相同的Linux用戶ID，在這種情況下，攝像頭，藍(lán)牙等設(shè)備的數(shù)據(jù)，所有應(yīng)用程序的權(quán)限必須由用戶在安裝時(shí)授予。用程序，并將那個(gè)部分的Java對象實(shí)例化。一個(gè)activity代表用戶界面的一個(gè)獨(dú)立屏幕。盡管所有activitie協(xié)同工作以構(gòu)成郵件應(yīng)用程序。照應(yīng)用程序能夠啟動郵件應(yīng)用程序的activity?；蛘呤菑木W(wǎng)絡(luò)上獲取數(shù)據(jù)，而不阻斷用戶與當(dāng)前activity的交互。如一個(gè)activity，為了與該service互動，可以啟動或者綁定它。用程序一些數(shù)據(jù)下載完成并處于可用狀態(tài)。所有的接收器均繼承自BroadcastReceiver基類。內(nèi)容提供者繼承于ContentProvider基。統(tǒng)會自動開始這個(gè)程序的進(jìn)程，并初始化這個(gè)組件所需要的相關(guān)類。

　　

【正文】 om other applications. You can declare an intent filter for your ponent by adding an intentfilter element as a child of the ponent39。s declaration element. For example, an application with an activity for posing a new might declare an intent filter in its manifest entry to respond to send intents (in order to send ). An activity in your application can then create an intent with the 20 “send” action (ACTION_SEND), which the system matches to the application’s “send” activity and launches it when you invoke the intent with startActivity(). For more about creating intent filters, see the Intents and Intent Filters document. Declaring application requirements There are a variety of devices powered by Android and not all of them provide the same features and capabilities. In order to prevent your application from being installed on devices that lack features needed by your application, it39。s important that you clearly define a profile for the types of devices your application supports by declaring device and software requirements in your manifest file. Most of these declarations are informational only and the system does not read them, but external services such as Google Play do read them in order to provide filtering for users when they search for applications from their device. For example, if your application requires a camera and uses APIs introduced in Android (API Level 7), you should declare these as requirements in your manifest file. That way, devices that do not have a camera and have an Android version lower than cannot install your application from Google Play. However, you can also declare that your application uses the camera, but does not require it. In that case, your application must perform a check at runtime to determine if the device has a camera and disable any features that use the camera if one is not available. Here are some of the important device characteristics that you should consider as you design and develop your application: Screen size and density In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical dimensions of the screen) and screen density (the physical density of the pixels on the screen, or dpi—dots per inch). 21 To simplify all the different types of screen configurations, the Android system generalizes them into select groups that make them easier to target. The screen sizes are: small, normal, large, and extra large. The screen densities are: low density, medium density, high density, and extra high density. By default, your application is patible with all screen sizes and densities, because the Android system makes the appropriate adjustments to your UI layout and image resources. However, you should create specialized layouts for certain screen sizes and provide specialized images for certain densities, using alternative layout resources, and by declaring in your manifest exactly which screen sizes your application supports with the supportsscreens element. For more information, see the Supporting Multiple Screens document. Input configurations Many devices provide a different type of user input mechanism, such as a hardware keyboard, a trackball, or a fiveway navigation pad. If your application requires a particular kind of input hardware, then you should declare it in your manifest with the usesconfiguration element. However, it is rare that an application should require a certain input configuration. Device features There are many hardware and software features that may or may not exist on a given Androidpowered device, such as a camera, a light sensor, bluetooth, a certain version of OpenGL, or the fidelity of the touchscreen. You should never assume that a certain feature is available on all Androidpowered devices (other than the availability of the standard Android library), so you should declare any features used by your application with the usesfeature element. Platform Version Different Androidpowered devices often run different versions of the Android 22 platform, such as Android or Android . Each successive version often includes additional APIs not available in the previous version. In order to indicate which set of APIs are available, each platform version specifies an API Level (for example, Android is API Level 1 and Android is API Level 9). If you use any APIs that were added to the platform after version , you should declare the minimum API Level in which those APIs were introduced using the usessdk element. It39。s important that you declare all such requirements for your application, because, when you distribute your application on Google Play, the store uses these declarations to filter which applications are available on each device. As such, your application should be available only to devices that meet all your application requirements. For more information about how Google Play filters applications based on these (and other) requirements, see the Filters on Google Play document. Application Resources An Android application is posed of more than just code—it requires resources that are separate from the source code, such as images, audio files, and anything relating to the visual presentation of the application. For example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using application resources makes it easy to update various characteristics of your application without modifying code and—by providing sets of alternative resources—enables you to optimize your application for a variety of device configurations (such as different languages and screen sizes). For every resource that you include in your Android project, the SDK build tools define a unique intege