Android官方文档word版资源-CSDN文库

共9个文件

docx：9个

3星 · 超过75%的资源需积分: 9 34 浏览量 2011-03-24 17:43:35 上传评论 1 收藏 10.21MB 7Z 举报

《Android 官方文档中文版》是一份针对国内开发者精心整理的资源，旨在解决因网络限制无法访问Android官网以及在线阅读不便的问题。这份文档包含了2011年3月24日更新的最新内容，是Android开发者的实用参考资料。本文将深入解析其中的关键知识点。一、Android开发基础 Android开发的基础部分涵盖了Android应用的基本结构和组件，包括Activity（活动）、Intent（意图）、Broadcast Receiver（广播接收器）、Service（服务）和Content Provider（内容提供者）。Activity是用户界面的核心，Intent用于在组件间传递消息。Broadcast Receiver可以监听系统或自定义广播事件，Service则是在后台执行长时间任务的组件，Content Provider则负责数据共享。二、UI设计与布局 Android提供了多种布局管理器，如LinearLayout（线性布局）、RelativeLayout（相对布局）、GridLayout（网格布局）和ConstraintLayout（约束布局）等，帮助开发者创建灵活多样的用户界面。此外，还介绍了自定义视图和动画的实现方法，提升用户体验。三、数据存储 Android提供了多种数据存储方式，包括Shared Preferences（首选项存储）、内部存储、外部存储、SQLite数据库和Content Provider。SQLite是轻量级的关系型数据库，适用于应用内的数据管理。四、网络通信 Android支持HTTP、HTTPS协议进行网络通信，可以通过HttpURLConnection、HttpClient、OkHttp等库实现。另外，还有WebSocket用于实现双向实时通信，以及FTP和SMTP用于文件传输和邮件发送。五、多媒体处理 Android官方文档详细介绍了如何处理音频、视频和图像。例如，MediaPlayer类用于播放音频和视频，Camera API用于拍照和录制视频，而Bitmap类则用于图像处理。六、传感器与设备交互 Android提供了Sensor Manager（传感器管理器）来访问设备的各种传感器，如加速度计、陀螺仪、磁力计等，实现运动检测和方向感知。七、通知与消息推送 Android的通知系统允许开发者向用户发送消息，即使应用不在前台运行。GCM（Google Cloud Messaging）和后来的FCM（Firebase Cloud Messaging）是用于实现消息推送的服务。八、权限管理 Android的权限系统确保了应用对敏感操作的访问控制。从Android 6.0开始，应用需要在运行时请求某些危险权限。九、性能优化文档还强调了性能优化的重要性，包括内存管理、CPU使用率、UI流畅性等方面的技巧，以及使用Profiler工具进行性能分析。十、测试与调试 Android提供了丰富的测试框架，如JUnit和Espresso，用于单元测试和UI测试。同时，Android Studio集成的调试工具可以帮助开发者定位和修复问题。十一、Gradle构建系统 Android使用Gradle作为构建工具，允许自定义构建过程，包括依赖管理、多模块项目配置和APK打包。十二、Android Studio与开发环境 Android Studio是官方推荐的IDE，集成了代码编辑、调试、性能分析等功能，支持快速开发和自动化构建。这份《Android 官方文档中文版》全面覆盖了Android开发的各个方面，对于初学者和有经验的开发者都是不可或缺的学习资料。通过深入学习，开发者可以更好地理解和利用Android平台，创建高效、稳定且用户体验优秀的应用程序。

资源推荐

资源详情

资源评论

收起资源包目录

Android Dev Guide.7z （9个子文件）

Android Dev Guide

Android Basics.docx 224KB

Web Applications.docx 319KB

Framework Topics.docx 2.42MB

Android Market Topics.docx 1.32MB

Appendix.docx 65KB

Publishing.docx 59KB

Best Practices.docx 6.71MB

Developing.docx 3.04MB

Contents.docx 23KB

Android Compatibility

See also

1. Market Filters

2. Providing Alternative Resources

3. Supporting Multiple Screens

4.  

5.  

6.  

7.  

8.  

9.  

Android is designed to run on many different types of devices. For developers, the range

and number of devices means a huge potential audience: the more devices that run

Android apps, the more users who can access your app. In exchange, however, it also

means that your apps will have to cope with that same variety of hardware.

Fortunately, Android has built-in tools and support that make it easy for your apps to do

that, while at the same time letting you maintain control of what types of devices your

app is available to. With a bit of forethought and some minor changes in your app's

manifest file, you can ensure that users whose devices can’t run your app will never see it

in the Android Market, and will not get in trouble by downloading it. This page explains

how you can control which devices have access to your apps, and how to prepare your

apps to make sure they reach the right audience.

What does “compatibility” mean?

A device is “Android compatible” if it can correctly run apps written for the Android

execution environment. The exact details of the Android execution environment are

defined by the Android Compatibility Definition Document, but the single most

important characteristic of a compatible device is the ability to install and correctly run an

Android  file.

There is exactly one Android API for each API level, and it’s the same API no matter

what kind of device it’s installed on. No parts of the API are optional, and you never have

to worry about parts of the API missing on some devices. Every compatible Android

device your app will land on will include every class and every API for that API level.

Of course, some APIs won’t work correctly if a particular device lacks the corresponding

hardware or feature. But that’s not a problem: we also designed Android to prevent apps

from being visible to devices which don’t have features the apps require. We’ve built

support for this right into the SDK tools, and it’s part of the Android platform itself, as

well as Android Market.

As a developer, you have complete control of how and where your apps are available.

Android provides tools as a first-class part of the platform that let you manage this. You

control the availability of your apps, so that they reach only the devices capable of

running them.

How does it work?

You manage your app’s availability through a simple three-step process:

1. You state the features your app requires by declaring  elements

its manifest file.

2. Devices are required to declare the features they include to Android Market.

3. Android Market uses your app’s stated requirements to filter it from devices that

don’t meet those requirements.

This way, users never even see apps that won’t work properly on their devices. As long

as you accurately describe your app’s requirements, you don’t need to worry about users

blaming you for compatibility problems.

If you’re familiar with web development, you may recognize this model as “capability

detection”. Web developers typically prefer this approach to “browser detection”,

because it’s very difficult to keep up as new browsers and new versions of current

browsers are released. By checking for support for specific required capabilities instead

of the current browser, web developers get better fine-grained control. That’s the same

approach Android uses: since it’s impossible to keep up with all the Android devices

being released, you instead use the fine-grained controls Android provides.

Filtering for technical reasons

Filtering on Android Market

Android Market filters the applications that are visible to users, so that users can see and

download only those applications that are compatible with their devices.

One of the ways Market filters applications is by feature compatibility. To do this,

Market checks the  elements in each application's manifest, to establish

the app's feature needs. Market then shows or hides the application to each user, based on

a comparison with the features available on the user's device.

For information about other filters that you can use to control the availability of your

apps, see the Market Filters document.

Android includes support for a lot of features, some hardware and some software.

Examples include compass and accelerometer sensors, cameras, and Live Wallpapers.

However, not every device will support every feature. For instance, some devices don’t

have the hardware horsepower to display Live Wallpapers well.

To manage this, Android defines feature IDs. Every capability has a corresponding

feature ID defined by the Android platform. For instance, the feature ID for compass is

, while the feature ID for Live Wallpapers is

. Each of these IDs also has a corresponding

Java-language constant on the   class that you can use to query whether

feature is supported at runtime. As Android adds support for new features in future

versions, new feature IDs will be added as well.

When you write your application, you specify which features your app requires by listing

their feature IDs in  elements in the ! " file. This is

the information that Android Market uses to match your app to devices that can run it.

For instance, if you state that your app requires android.software.live_wallpapers, it

won’t be shown to devices that don’t support Live Wallpapers.

This puts you in total control of your app — because you don’t have to declare these

features. Consider an example involving cameras.

If you’re building a really impressive next-generation augmented-reality app, your app

won’t function at all without a camera. However, if you’re building a shopping app that

only uses the camera for barcode scanning, users without cameras might still find it

useful even if they can’t scan barcodes. While both apps need to acquire the permission

to access the camera, only the first app needs to state that it requires a camera. (The

shopping app can simply check at runtime and disable the camera-related features if

there’s no camera present.)

Since only you can say what the best approach is for your app, Android provides the tools

and lets you make your own tradeoff between maximizing audience size and minimizing

development costs.

Filtering for business reasons

It’s possible that you may need to restrict your app’s availability for business or legal

reasons. For instance, an app that displays train schedules for the London Underground is

unlikely to be useful to users outside the United Kingdom. Other apps might not be

permitted in certain countries for business or legal reasons. For cases such as these,

Android Market itself provides developers with filtering options that allow them control

their app’s availability for non-technical reasons.

The help information for Android Market provides full details, but in a nutshell,

developers can use the Market publisher UI to:

 List the countries an app is available in.

 Select which carrier’s users are able to access the app.

Filtering for technical compatibility (such as required hardware components) is always

based on information contained within your  file. But filtering for non-technical

reasons (such as geographic restrictions) is always handled in the Market user interface.

Future-proofing

There’s one additional quirk that we haven’t yet addressed: protecting apps from changes

made to future versions of Android. If the Android platform introduces a new feature or

changes how existing features are handled, what happens to existing apps that were

written without any knowledge of the new behavior?

Simply put, Android commits to not making existing apps available to devices where

they won’t work properly, even when the platform changes. The best way to explain this

is through examples, so here are two:

 Android 1.0 through 1.5 required a 2 megapixel camera with auto-focus.

However, with version 1.6, Android devices were permitted to omit the auto-

focus capability, though a (fixed-focus) camera was still required. Some apps

such as barcode scanners do not function as well with cameras that do not auto-

focus. To prevent users from having a bad experience with those apps, existing

apps that obtain permission to use the Camera were assumed by default to require

auto-focus. This allowed Android Market to filter those apps from devices that

lack auto-focus.

 Android 2.2, meanwhile, allowed the microphone to be optional on some devices,

such as set-top boxes. Android 2.2 included a new feature ID for the microphone

which allows developers to filter their apps if necessary, but — as with camera —

apps that obtain permission to record audio are assumed to require the

microphone feature by default. If your app can use a microphone but doesn’t

strictly need it, you can explicitly state that you don’t require it; but unless you do

that, your app won’t be shown to devices without microphones.

In other words, whenever Android introduces new features or changes existing ones, we

will always take steps to protect existing applications so that they don’t end up being

available to devices where they won’t work.

This is implemented, in part, using the  tool in the SDK. To see which features your

app explicitly requires or is implicitly assumed to require, you can use the command

.

Conclusion

The goal of Android is to create a huge installed base for developers to take advantage of.

One of the ways we will achieve this is through different kinds of hardware running the

same software environment. But we also recognize that only developers know which 
kinds of devices their apps make sense on. We’ve built in tools to the SDK and set up 
policies and requirements to ensure that developers remain in control of their apps, today 
and in the future. With the information you just read, and the resources listed in the 
sidebar of this document, you can publish your app with the confidence that only users 
who can run it will see it.
For more information about Android device compatibility, please visit:
http://source.android.com/compatibility/index.html
Supporting Multiple Screens
Quickview
 
 
 
  !"#
 $%%

 "&%%

In this document
' $(( 
' ) 
* + 
, - 
. /0% 
1 )2  
* 34(" 
, (5 
. + 
See Also
'  
*  
, 4) 
. 6/7- 