有關(guān)android技術(shù)英文文獻翻譯(編輯修改稿)

　

【文章內(nèi)容簡介】 subclass and theandroid:labelattributes specifies a string to use as the uservisible label for the activity. You must declare all application ponents this way:l activityelements for activitiesl serviceelements for servicesl receiverelements for broadcast receiversl providerelements for content providers Activities, services, and content providers that you include in your source but do not declare in the manifest are not visible to the system and, consequently, can never run. However, broadcast receivers can be either declared in the manifest or created dynamically in code (asBroadcastReceiverobjects) and registered with the system by callingregisterReceiver().Declaring ponent capabilities As discussed above, inActivating Components, you can use anIntentto start activities, services, and broadcast receivers. You can do so by explicitly naming the target ponent (using the ponent class name) in the intent. However, the real power of intents lies in the concept of intent actions. With intent actions, you simply describe the type of action you want to perform (and optionally, the data upon which you’d like to perform the action) and allow the system to find a ponent on the device that can perform the action and start it. If there are multiple ponents that can perform the action described by the intent, then the user selects which one to use. The way the system identifies the ponents that can respond to an intent is by paring the intent received to theintent filtersprovided in the manifest file of other applications on the device. When you declare a ponent in your application39。s manifest, you can optionally include intent filters that declare the capabilities of the ponent so it can respond to intents from other applications. You can declare an intent filter for your ponent by adding anintentfilterelement 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 “send” action (ACTION_SEND), which the system matches to the application’s “send” activity and launches it when you invoke the intent withstartActivity(). For more about creating intent filters, see theIntents and Intent Filtersdocument.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 Level7), you should declare these as requirements in your manifest file. That way, devices that donothave a camera and have an Android versionlowerthan cannot install your application from Google Play. However, you can also declare that your application uses the camera, but does notrequireit. 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 densityIn 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). 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 thesupportsscreenselement.For more information, see theSupporting Multiple Screensdocument.Input configurationsMany 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 theusesconfigurationelement. However, it is rare that an application should require a certain input configuration.Device featuresThere 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 theusesfeatureelement.Platform VersionDifferent Androidpowered devices often run different versions of the Android 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 ver