The <uses-permission> Element
我们现在告别<application>元素，回到<manifest>中定义的子元素，<uses-permission>就是我们接下来要讨论的其中一个元素。
Android有一个精心设计的安全模型。每一个应用都有其自己Linux用户和群组，在单独的进程和VM上运行，不能影响到其他应用。android同时也限定了系统资源的使用，像网络设备，SD卡，录音设备等。如果你的应用希望去使用任何系统资源，我们必须去申请Android的权限。这就是<uses-permission>元素的作用。
一个权限通常有以下格式，用一个名字为name 的字符串去指导我们希望使用的权限。
<uses-permission android:name="string"/>
这有一些可能会使用到的权限名：
android.permission.RECORD_AUDIO: 它允许我们使用录音设备。
android.permission.INTERNET: 它允许我们使用全部的networking APIs，举个例子，从网上得到一个图片或者更新网上的最高
分数。
android.permission.WRITE_EXTERNAL_STORAGE:它允许我们去读写外部存储设备，通常是设备的SD卡。
android.permission.WAKE_LOCK:它允许我们去锁定一个所谓的wake lock,使用wake lock我们可以避免在进行游戏的时候设
备休眠（在屏幕长时间没有被触屏时）。举个例子，这种情况何能出现在只是用加速传感器的时候。
想要获得networking APIs的使用权限，我们指定如下的元素作为 <manifest>的子元素。
<uses-permission android:name="android.permission.INTERNET"/>
如果还需要添加其他的元素，我们只需简单的添加更多的<uses-permission>就行了。你还有很多其他的权限可以指定，我再次
建议你去查询Android官方文档。我们只需要使用到刚才我们讨论的哪几个元素就行了。
忘记去添加一些如使用SD卡的权限会产生一个公共的错误，manifests在LogCat里面有消息，但是可能不会在杂乱的
LogCat当中被发现。思考什么权限是游戏需要的，然后在开始游戏开发之前指定它们。
另一方面需要注意的是，当用户安装你的应用的时候，用户会先游览应用所需要的权限。或许有些用户会跳过这些，然后开开
心心的把应用安装上，不管他们会不会着道。另外一些用户可能会有意识的去游览权限。如果你的应用带有一些敏感权限，像使
发送大量的短信或者得到使用者的位置，你就可能会在google market收到不好的评价。 如果你使用了一个有问题的敏感权限，
就去告诉用户你为什么要使用它。最好的办法是去避免使用这些敏感权限。
下一个是<uses-feature>
附上原文：
The <uses-permission> Element
We are leaving the <application> element now and coming back to elements we define
as children of the <manifest> element. One of these elements is the <uses-permission>
element.
Android has an elaborate security model. Each application is run in its own process and
VM, with its own Linux user and group, and cannot influence other applications. Android
also restricts the use of system resources, such as networking facilities, the SD card,
and the audio-recording hardware. If our application wants to use any of these system
resources, we have to ask for permission. This is done with the <uses-permission>
element.
A permission always has the following form, where string specifies the name of the
permission we want to be granted:
<uses-permission android:name="string"/>
Here are a few permission names that might come in handy:
android.permission.RECORD_AUDIO: This grants us access to the
audio-recording hardware.
android.permission.INTERNET: This grants us access to all the
networking APIs so we can, for example, fetch an image from the Net
or upload high-scores.
android.permission.WRITE_EXTERNAL_STORAGE: This allows us to read
and write files on the external storage, usually the SD card of the
device.
android.permission.WAKE_LOCK: This allows us to acquire a so-called
wake lock. With this wake lock we can keep the device from going to
sleep if the screen hasn’t been touched for some time. This could
happen in a game that is controlled only by the accelerometer, for
example.
To get access to the networking APIs, we’d thus specify the following element as a child
of the <manifest> element:
<uses-permission android:name="android.permission.INTERNET"/>
For any additional permissions, we simply add more <uses-permission> elements. There
are many more permissions you can specify; I again refer you to the official Android
documentation. We’ll only need the set just discussed.
Forgetting to add a permission for something like accessing the SD card is a common
error source that manifests itself as a message in LogCat, which might survive
undetected due to all the clutter in LogCat. Think about the permissions your game will
need and specify them when you create the project initially.
Another thing to notice is that when a user installs your application, she will first be
asked to review all the permissions your application wants. Many users will just skip
reading those and happily install whatever they can get ahold of. Some users are more
conscious about their decisions and will review the permissions in detail. If you request
suspicious permissions, like the ability to send out costly SMS messages or get a user’s
location, you may receive some nasty feedback from users in the Comments section for
your application in the market. If you use one of those problematic permissions, then tell
the user why you’re using it in your application description. The best thing is to avoid
those permissions in the first place, though.