編輯:關於Android編程
由上篇Android Permission權限機制引子,我們知道Android 通過在每台設備上實施了基於權限的安全策略來處理安全問題,采用權限來限制安裝應用程序的能力。本篇文章繼續來探討和Android權限相關的話題,主要集中在權限級別、ICC(inter- component communication)權限保護兩個方面。
權限級別 protection level
每一個Permission權限都設有了權限級別(protection level),分別如下:
復制代碼 代碼如下:
“normal”
The default value. A lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application at installation, without asking for the user's explicit approval (though the user always has the option to review these permissions before installing).
normal級別是一些比較低風險的權限,我們在安裝一個新app到手機時,一般會被折疊起來的權限就是normal級別的。
復制代碼 代碼如下:
“dangerous”
A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Because this type of permission introduces potential risk, the system may not automatically grant it to the requesting application. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities.
dangerous則是那些比較高風險的權限,在安裝時會明顯提示用戶該app具有這些權限,並且需要用戶同意確認才能正確安裝app的權限。
復制代碼 代碼如下:
“signature”
A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.
signature則在我們用戶自定義權限custom時,會用得到的,具體做法我會在另一篇博文:Android 自定義權限中具體研究的,這裡簡述之:
用戶在某一個app(先稱permisson app)中自定義了permission時,並且指定了某些組件需要該自定義權限才能打開,這是前提,然後用戶又開發了另外一個app(稱為permission client),這個permission client如果想訪問permisson app中指定了自定義權限的組件,那麼這兩個app必須具備相同的signature,這就是signature級別的意思。
復制代碼 代碼如下:
“signatureOrSystem”
A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificates as those in the system image. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The “signatureOrSystem” permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
這個同上,但多了一個Or,or是指除了相同的signature之外還可以指定為相同的Android img也可以訪問,這個img其實就是系統級別的定制了,一般用的很少。
ICC(inter-component communication)權限保護
<application>元素和組件元素都有android:permission的屬性,在這裡我們稱這個屬性分別為應用程序和組件的權限標簽。應用程序內的組件可以繼承應用程序元素設置的權限標簽,當某一組件啟動 ICC 時,相關的訪問控制器就會查看組件和組件所在應用程序的權限標簽集合,如目標組件的訪問權限標簽在以上的集合內,允許 ICC 的建立繼續進行,否則將會被拒絕,即使這兩個組件在同一應用程序內。
改圖描述了該邏輯的進程:組件A是否可以訪問組件B和C,取決於比較B和C內的訪問權限標簽與應用程序1內的標簽集合的結果。B和應用程序1內都有i1標簽,所以組件A可以訪問組件B,相反應用程序1內沒有標簽i2,組件A 不可以訪問組件B。
ReactNative的發展已經進入了很多開發者視野,作為一名原生開發者更是對 RN 充滿了無限的好奇和期待,本節將詳細講述如何將一個原生的 Android App 項目
第1節 ContentProvider介紹ContentProvider是安卓系統的四大組件之一,可以向其他組件提供數據訪問的能力。它就像是一個網站,其他組件(或者其他應
dom 我的理解就是先把整個文檔讀取到內存中,然後才解析,讀取大點的文件的話這樣效率就會很低。而 sax和pull 它們是基於事件解析的。一行一行去解析,效率會高點。下面
之前打包的時候直接就用eclipse或者android studio直接生成簽名文件,並沒有關心大小問題,最近有人問我有沒有對APK進行瘦身,對這方面內容一致沒有關注過,