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.
