Android外文文献翻译

1、An droid Applicati on Fun dame ntalsAn droid applicatio ns are writte n in the Java program ming Ian guage. The An droid SDK tools compile the code along with any data and resource file into an An droid package, an archive an .apk suffix. All the code in a single .apk considered to be one applicatio

2、n and is the An droid-powered devices use to in stall the applicatio n.Once in stalled on a device, each An droid applicati on lives in its own security san dbox:The An droid operati ng system is a multi-user Linux system in which each applicatio n is a differe nt user.By default, the system assigns

3、 each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.Each process has its own virtual machine (VM), so an a

4、pplication's code runs in isolation from other applicati ons.By default, every applicatio n runs in its own Linux process. An droid starts the process whe n any of the applicati on's comp onents n eed to be executed, the n shuts dow n the process whe n it's no Ion ger n eeded or whe n th

5、e system must recover memory for other applicati ons. In this way, the An droid system impleme nts thepri nciple of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure en vir onment in which

6、 an applicati on cannot access parts of the system for which it is not give n permissi on.However, there are ways for an applicati on to share data with other applicati ons and for an applicati on to access system services:It's possible to arrange for two applicati ons to share the same Linux us

7、er ID, in which case they are able to access each other's files. To con serve system resources, applicati ons with the same user ID can also arrange to run in the same Linux process and share the same VM (the applications must also be signed with the same certificate).An applicatio n can request

8、 permissi on to access device data such as the user's con tacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All applicatio n permissi ons must be gran ted by the user at in stall time.That covers the basics regardi ng how an An droid applicati on exists withi n t

9、he system. The rest of this docume nt in troduces you to:1、The core framework components that define your application.2、The manifest which you declare components and required device features for your applicati on.3、Resources that are separate from the application code and allow your application to g

10、racefully optimize its behavior for a variety of device con figurati ons.Applicati on Comp onentsApplicatio n comp onents are the esse ntial build ing blocks of an An droid applicati on. Each comp onent is a differe nt point through which the system can en ter your applicati on. Not all comp onents

11、are actual entry points for the user and some depe nd on each other, but each one exists as its own entity and plays a specific roeach one is a unique building block that helps define your application's overall behavior.There are four differe nt types of applicati on comp onen ts. Each type serv

12、es a disti net purpose and has a distinct lifecycle that defines how the component is created and destroyed.Here are the four types of applicati on comp onen ts:ActivitiesAn activity represe nts a sin gle scree n with a user in terface. For example, an email application might have one activity that

13、shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experie nee in the email applicati on, each one is in depe ndent of the others. As such, a different application can start any one

14、of these activities (if the email application allows it). For example, a camera application can start the activity in the email applicati on that composes new mail, in order for the user to share a picture.An activity is implemented as a subclass oActivity and you can leann more about it in the Acti

15、vities developer guide.ServicesA serviceis a comp onent that runs in the backgro und to perform long-running operatio ns or to perform work for remote processes.A service does not provide a user in terface. For example, a service might play music in the background while the user is in a different ap

16、plication, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to in teract with it.A service is implemented as a subclass of Service and you can learn more abo

17、ut it in the Services developer guide.Content providersA content provider man ages a shared setof applicatio n data. You can store the data in the , an SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications

18、can query or even modify the data (if the content provider allows it). For example, the An droid system provides a content provider that man ages the user's con tact in formatio n. As such, any applicati on with the proper permissi ons can query part of the content provider (such asC on tactsC o

19、n tract.Data) to read and write in formati on about a particular pers on.Content providers are also useful for reading and writing data that is private to your application and not shared. For example, theNote Pad sample application uses a content provider to save no tes.A content provider is impleme

20、nted as a subclass oContentProvider and must implement a standard set of APIs that enable other applications to perform transactions. For more in formati on, see theCo ntent Providers developer guide.Broadcast receiversA broadcast receiver is a component that responds to system-wide broadcast announ

21、 ceme nts. Many broadcasts orig in ate from the system for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Applications can also initiate broadcasts-for example, to let other applications know that some data has been downloaded to the de

22、vice and is available for them to use. Although broadcast receivers don't display a user in terface, they mayreate a status bar notificati on to alert the user whe n a broadcast eve nt occurs. More com monly, though, a broadcast receiver is just a "gateway" to other comp onents and is

23、inten ded to do a very mini mal amount of work. For in sta nee, it might in itiate a service to perform some work based on the eve nt.A broadcast receiver is impleme nted as a subclass BfoadcastReceiver and each broadcast is delivered as anintent object. For more information, seethe BroadcastReceive

24、r class.A unique aspect of the An droid system desig n is that any applicati on can start ano ther application' s component. For example, if you wansthretoucapture a photo with the devicecamera, there's probably ano ther applicati on that does that and your applicati on can use it, in stead

25、of develop ing an activity to capture a photo yourself. You don't n eed to in corporate or eve n link to the code from the camera applicati on. In stead, you can simply start the activity in the camera application that captures a photo. When complete, the photo is even returned to your applicati

26、on so you can use it. To the user, it seems as if the camera is actually a part of your applicati on.When the system starts a component, it starts the process for that application (if it's not already running) and in sta ntiates the classes n eeded for the comp onent. For example, if your applic

27、ation starts the activity in the camera application that captures a photo, that activity runs in the process that bel ongs to the camera applicati on, not in your applicatio n's process. Therefore, un like applicati ons on most other systems, An droid applicatio ns don't have a sin gle entry

28、 point (there's nomain() function, for example).Because the system runs each applicatio n in a separate process witthat restrict access to other applicati ons, your applicati on cannot directly activate a comp onent from ano ther applicatio n. The An droid system, however, can. So, to activate a

29、 comp onent in ano ther applicati on, you must deliver a message to the system that specifies yoinite nt to start a particular comp onent. The system the n activates the comp onent for you.Activati ng Comp onentsThree of the four comp onent type activities, services, and broadcast receiveare activat

30、ed by an asynchronous message called airten t. I ntents bind in dividual comp onents to each other at run time (you can thi nk of them as the messe ngers that request an acti on from other comp onen ts), whether the comp onent bel ongs to your applicati on or ano ther.An intent is created with anint

31、entobject, which defines a message to activate either a specific comp onent or a specifictype of comp onentan intent can be either explicit or implicit, respectively.For activities and services, an intent defines the action to perform (for example, to "view" or "se nd" somethi ng

32、) and may specify the URI of the data to act on (am ong other thi ngs that the comp onent being started might n eed to kno w). For example, an intent might con vey a request for an activity to show an image or to ope n a web page. In some cases, you can start an activity to receive a result, in whic

33、h case, the activity also returns the result in an Intent (for example, you can issue an intent to let the user pick a pers onal con tact and have it retur ned to youthe return intent in cludes a URI pointing to the chose n con tact).For broadcast receivers, the intent simply defi nes the announ cem

34、e nt being broadcast (for example, a broadcast to indicate the device battery is low includes only a known action string that in dicates "battery is low").The other component type, content provider, is not activated by intents. Rather, it is activated whe n targeted by a request frona Cont

35、en tResolver The content resolver han dles all direct tran sacti ons with the content provider so that the comp onent that's perform ing tran sacti ons with the provider does n't n eed to and in stead calls methods on the Con te ntResolverobject. This leaves a layer of abstracti on betwee n

36、the content provider and the comp onent requesti ng in formatio n (for security).There are separate methods for activati ng each type of comp onent:You can start an activity (or give it someth ing new to do) by pass ingan Intent to startActivity() or startActivityForResult() (when you want the activ

37、ity to return a result).You can start a service (or give new in structi ons to an ongoing service) by pass ing an Intent to startService(). Or you can bind to the service by pass ingin Intent tobi ndService().You can in itiate a broadcast by pass ing annte nt to methodslike sen dBroadcast(), sen dOr

38、deredBroadcast(), or sen dStickyBroadcastjf.You can perform a query to a content provider by calli ngquery() on aco nten tResolver.For more in formatio n about using in ten ts, see thente nts and Intent Filters docume nt. More in formatio n about activati ng specific comp onents is also provided in

39、the followi ng documents：Activities, Services, BroadcastReceiver and Content Providers .Declari ng comp onentsThe primary task of the manifest is to inform the system about the application'scomp onen ts. For example, a man ifest declare an activity as follows:<?xml versio n="1.0" en

40、 codi ng="utf-8"?><ma ni fest . ><applicati on an droid:ic on="drawable/app_ic on .p ng" . ><activity an droid:n ame="ject.ExampleActivity" android:label="string/example_label" . ></activity></applicati on></m

41、a nifest>In the <application> element, the android:icon attribute points to resources for an icon that ide ntifies the applicatio n.In the <activity> eleme nt, the an droid:n ameattribute specifies the filly qualified class name of the Activity subclass and the android:labelattributes

42、 specifies a string to use as the user-visible label for the activity.You must declare all applicatio n comp onents this way:1、<activity > elements for activities2、<service> elements for services3、<receiver> elements for broadcast receivers4、<provider > elements for content p

43、rovidersActivities, services, and content providers that you in clude in your source but do not declare in the mani fest are not visible to the system and, con seque ntly, can n ever run. However, broadcast receivers can be either declared in the mani fest or created dyn amically in code (asBroadcas

44、tReceiverobjects) and registered with the system by calli ng registerReceiver()Declaring component capabilitiesAs discussed above, in Activati ng Comp onen tsyou can usea n Intent to start activities, services, and broadcast receivers. You can do so by explicitly naming the target comp onent (us ing

45、 the comp onent class n ame) in the intent. However, the real power of intents lies in the con cept of intent actions. With intent acti ons, you simply describe the type of action you want to perform (and opti on ally, the data upon which you' d like to perform the action) and allothe system to

46、find a component on the device that can perform the action and start it. If there are multiple comp onents that can perform the acti on described by the intent, the n the user selects which one to use.The way the system identifies the components that can respond to an intent is by comparing the inte

47、nt received to theintent filters provided in the manifest other applications on the device.When you declare a comp onent in your applicati on's man ifest, you can opti on ally in clude intent filters that declare the capabilities of the component so it can respond to intents from other applicati

48、 ons. You can declare an in tenfilter for your comp onent by add ing an vintent-filter > element as a child of the component's declaration element.For example, an email application with an activity for composing a new email might declare an intent filter in its mani fest en try to resp ond to

49、 "se nd" intents (in order to send email). An activity in your applicati on can the n create an intent with the " actio n“ sene(ACTION_SEND ), which the system matches to the email application " activltysand send launches it when you invoke the intent withstartActivity().For more

50、 about creating intent filters, see thentents and Intent Filtersdocument.Declari ng applicati on requireme ntsThere are a variety of devices powered by An droid and not all of them provide the same features and capabilities. In order to preve nt your applicatio n from being in stalled on devices tha

51、t lack features needed by your application, it's important that you clearly define a pro the types of devices your applicati on supports by declari ng device and software requireme nts in your manifest file. Most of these declarations are informational only and the system does not read them, but

52、 external services such as Google Play do read them in order to provide filtering for users whe n they search for applicati ons from their device.For example, if your applicati on requires a camera and uses APIs in troduced in An droid 2.1 (API Level 7), you should declare these as requirements in y

53、our manifest file. That way, devices that donot have a camera and have an An droid versidower tha n 2.1 cannot in stall your applicati on from Google Play.However, you can also declare that your applicati on uses the camera, but does not require it. I n that case, your applicati on must perform a ch

54、eck at run time to determ ine if the device has a camera and disable any features that use the camera if one is not available.Here are some of the importa nt device characteristics that you should con sider as you desig n and develop your applicati on:Scree n size and den sityIn order to categorize

55、devices by their scree n type, An droid defi nes two characteristics for each device: screen size (the physical dimensions of the screen) and screen density (the physical den sity of the pixels on the scree n, or dpidots per in ch). To simplify all the differe nt types of scree n con figurati ons, t

56、he An droid system gen eralizes them in to select groups that make them easier to target.The scree n sizes are: small, no rmal, large, and extra large.The screen densities are: low density, medium density, high density, and extra high density.By default, your applicati on is compatible with all scre

57、e n sizes and den sities, because the An droid system makes the appropriate adjustme nts to your UI layout and image resources. However, you should create specialized layouts for certa in scree n sizes and provide specialized images for certa in den sities, using alter native layout resources, and b

58、y declari ng in your mani fest exactly which scree n sizes your applicati on supportw ith the <supports-scree ns> eleme nt.For more in formatio n, see the Support ing Multiple Scree ns docume nt.In put con figurati onsMany devices provide a different type of user input mechanism, such as a har

59、dware keyboard, a trackball, or a five-way navigation pad. If your application requires a particular kind of in put hardware, the n you should declare it in your mani fest with the <uses-configuration> element.However, it is rare that an application should require acerta in in put con figurati

60、 on.Device featuresThere are many hardware and software features that may or may not exist on a give n An droid-powered device, such as a camera, a light sen sor, bluetooth, a certa in versi on of OpenGL, or the fidelity of the touchscreen. You should never assume that a certain feature is available on all An droid-powered devices (other tha n the availability of the sta ndard