androidapi對應

⑴ android api 簽名是什麼意思

首先我們得知道什麼是摘要，摘要是指採用單向Hash函數對數據進行計算生成的固定長度的Hash值，摘要演算法有Md5，Sha1等，Md5生成的Hash值是128位的數字，即16個位元組，用十六進製表示是32個字元，Sha1生成的Hash值是160位的數字，即20個位元組，用十六進製表示是40個字元。我們是不能通過摘要推算出用於計算摘要的數據，如果修改了數據，那麼它的摘要一定會變化(其實這句話並不正確，只是很難正好找到不同的數據，而他們的摘要值正好相等)。摘要經常用於驗證數據的完整性，很多下載網站都會列出下載文件的md5值或者sha1值。
摘要和簽名沒有任何關系，網上常常將摘要和簽名混為一談，這是錯誤的。簽名和數字簽名是同一個概念，是指信息的發送者用自己的私鑰對消息摘要加密產生一個字元串，加密演算法確保別人無法偽造生成這段字元串，這段數字串也是對信息的發送者發送信息真實性的一個有效證明。其他發送者用他們的私鑰對同一個消息摘要加密會得到不同的簽名，接收者只有使用發送者簽名時使用的私鑰對應的公鑰解密簽名數據才能得到消息摘要，否則得到的不是正確的消息摘要。
數字簽名是非對稱密鑰加密技術+數字摘要技術的結合。
數字簽名技術是將信息摘要用發送者的私鑰加密，和原文以及公鑰一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的信息摘要，然後接收者用相同的Hash函數對收到的原文產生一個信息摘要，與解密的信息摘要做比對。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改；不同則說明信息被修改過，因此數字簽名能保證信息的完整性。並且由於只有發送者才有加密摘要的私鑰，所以我們可以確定信息一定是發送者發送的。
另外還需要理解一個概念：數字證書。數字證書是一個經證書授權中心數字簽名的包含公鑰及其擁有者信息的文件。數字證書的格式普遍採用的是X.509V3國際標准，一個標準的X.509數字證書包含以下一些內容：證書的版本信息:
1)證書的序列號，每個證書都有一個唯一的證書序列號；
2)證書所使用的簽名演算法；
3)證書的發行機構名稱，命名規則一般採用X.500格式；
4)證書的有效期，通用的證書一般採用UTC時間格式，它的計時范圍為1950-2049；
5)證書所有人的名稱，命名規則一般採用X.500格式；
6)證書所有人的公開密鑰；
7)證書發行者對證書的簽名。
CERT.RSA包含了數字簽名以及開發者的數字證書。CERT.RSA里的數字簽名是指對CERT.SF的摘要採用私鑰加密後的數據，Android系統安裝apk時會對CERT.SF計算摘要，然後使用CERT.RSA里的公鑰對CERT.RSA里的數字簽名解密得到一個摘要，比較這兩個摘要便可知道該apk是否有正確的簽名，也就說如果其他人修改了apk並沒有重新簽名是會被檢查出來的。
需注意Android平台的證書是自簽名的，也就說不需要權威機構簽發，數字證書的發行機構和所有人是相同的，都是開發者自己，開發者生成公私鑰對後不需要提交到權威機構進行校驗。

⑵ Android 13 適配指南

2022 的Google I/O 發布了 Android 13 beta 2 和 Android 13 Beta 1 國內廠商的設備支持列表，雖然按照慣例， Android 13 應該是年末才發布正式版，但是相信有的開發者已經收到了平台的 Android13 的適配要求，所以本篇也是結合 Oppo 的 Android 13 應用兼容性適配指導 和官方提供的一些文檔內容做一個整理測試。

目前 Android 13 主要的兼容問題還是在於隱私許可權上，所以本次的適配指南相關內容也是著重在這一部分， 這里涉及面比較廣的應該就是相冊和通知許可權 。

這個動圖大家可能看到過， 這是 Android 13 上提供的系統圖片選擇器，通過 Intent(MediaStore.ACTION_PICK_IMAGES); 就可以打開，支持視頻、音頻、圖片分類，支持多選和單選 ，另外官方也表示過，這個特性不僅僅會在 Android 13 中出現，谷歌還會將其放置到 Play 商店中，向 Android 11 和 Android 12 設備推送。

我們通過調整 TargetSDK 設置為 PreView ，然後運行到 Tiramisu 的模擬器上進行測試，主要測試 TargetSDK 在低於 "Tiramisu" 和等於 "Tiramisu" 時的不同情況。

如下圖所示：

總結： 所以如果是 TargetSDK 在 Android 13 以下，不需要處理，如果在 Android 13 以及以上 ，需要增加申請許可權 。

在 Android R 上設置里開始支持在設置里對應用的通知許可權進行管理，但是應用自身是無法修改應用級別的通知許可權，所以 App 無法知道自身有沒有發送通知的許可權

所以在 Android 13 里增加了通知的運行時許可權 ，其中 Android 13 (33) 的通知會根據正在運行的應用程序的目標 API 級別進行不同的處理， 不過不管應用程序的目標API級別如何，Android 13 都會提示用戶授予應用程序發送通知的許可權 。

例如下圖，是 targetSdk 30 運行在 Android 13 模擬器上，依然會彈出讓用戶是否允許推送 。

當然，系統也會根據應用程序的目標 API 級別處理通知訪問:

如果是 現有應用更新 ，程序的目標 API 級別為：

最後測試和總結一下：

由於 Android 之前可以通過跟蹤附近的 Wi-Fi AP 和藍牙設備來推斷設備的位置，所以這次谷歌決定禁止應用程序 訪問藍牙 結果，除非這類應用需要聲明 ACCESS_FINE_LOCATION 許可權。

在 Android 13 中，Google 將 Wi-Fi 掃描與位置相關內容分離， Android 13 為管理設備與周圍 Wi-Fi 熱點連接的應用添加 NEARBY_WIFI_DEVICES 運行時許可權 (屬於 NEARBY_DEVICES 許可權組)，從而在不需要 ACCESS_FINE_LOCATION 許可權的情況下，也可以讓應用訪問附近的 Wi-Fi 設備。

此前，對於僅需要連接 Wi-Fi 設備，但實際上並不需要了解設備位置的應用來說，以 Android 13 (33)為目標平台的應用現在可以通過 「 neverForLocation 」 屬性來完善申請 NEARBY_WIFI_DEVICES 許可權。

這項新許可權會影響幾個不同的 Wi-Fi 用例，包括以下用例：

所以開發需要區分不同api對應的許可權；

由於 NEARBY_WIFI_DEVICES 許可權僅適用於 Android 13 或更高版本， 如果是 Android12L(32) 以及以下的 App 應保留對 ACCESS_FINE_LOCATION 的所有聲明：

以 Android 13(33) 為目標平台時，如果應用不會通過 Wi-Fi API 推導物理位置，請在清單文件中將 usesPermissionFlags 屬性設為 neverForLocation。

所以總結： 以 Android 13(33) 為目標平台的應用程序，訪問附近的 WI-FI 設備。除特例API需要申請ACCESS_FINE_LOCATION外，其他需要申請 android.permission.NEARBY_WIFI_DEVICES 運行時許可權 ；

Android 13 中引入了 「在使用時」 訪問身體感測器（例如心率、體溫和血氧飽和度）的概念，此訪問模式與 Android 10（API 級別 29）系統為位置信息 引入的模式非常相似。

如果你的 App 以 Android 13(33) 為目標平台，並且在後台運行時需要訪問身體感測器信息，那麼除了現有的 BODY_SENSORS 許可權外，還必須聲明新的 BODY_SENSORS_BACKGROUND 許可權 。

當 App 以 Android 13(33) 或更高版本為 Target 的其他應用的導出組件發送 intent 時，僅當該 intent 與接收應用中的 <intent-filter> 元素匹配時，系統才會傳送該 intent，換言之系統會屏蔽所有不匹配的 intent，但以下情況除外：

為了幫助提高運行時接收器的安全性，Android 13 允許你指定 App 中的特定廣播接收器是否應被導出以及是否對設備上的其他應用可見，此變更是 Android 12 更安全的組件 的延續；

以 Android 13(33) 或更高版本為目標平台的應用，必須為每個廣播接收器指定 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED ，否則當 App 嘗試注冊廣播接收器時，系統會拋出 SecurityException

在 Android 13中，谷歌添加了一個新的API，允許開發者降級許可權。

應用程序可以觸發撤銷授予調用 API 的包的一個或多個運行時許可權，不需要訪問特定運行時許可權控制 API 的應用程序可以自行撤銷這些許可權，這樣用戶就可以確保這些應用程序不會在不知情的情況下使用這些API。

如需撤消特定運行時許可權，請將該許可權的名稱傳入 revokeOwnPermissionOnKill() 方法，如需同時撤消一組運行時許可權，請將這組許可權的名稱傳入 revokeOwnPermissionsOnKill() 。

系統只有在安全的情況下才會觸發撤消操作，也就是當有應用組件仍在前台運行，或者有另一個應用正在訪問你應用的組件（如 content provider）時不會發生撤消。

Android 之前一直提供了一個剪貼板服務，所有 App 都可以使用它來放置和檢索文本。

盡管從技術上講，任何應用都可以清除全局剪貼板中的主內容（只要它們是前台應用或 Android 10+ 上的默認輸入法），但 Android 本身不會自動清除剪貼板。

這意味著任何留在全局剪貼板中的剪貼板內容，都可以在以後被應用程序讀取，盡管 Android 的剪貼板訪問有 toast 消息可能會提醒用戶。

Android 13 增加了剪貼板自動清除功能，此功能在默認情況下處於禁用狀態，在經過設定的時間後，將自動從全局剪貼板中清除主剪輯， 默認情況下經過3600000毫秒（60分鍾）後，剪貼板將被清除。

每次執行復制/讀取（寫入剪貼板 setPrimaryClip ，讀 getPrimaryClip ）時，會重置一個消息 timeout（60min），之後會自動清除剪貼板內存中的內容，即60min內，如果一直沒有寫入剪貼板的操作，剪貼板的內容會被自動清除。

Android 13 的新前台服務（ Foreground Services：FGS）任務管理器顯示當前運行前台服務的應用程序列表，此列表稱為活動應用程序，可以通過下拉通知抽屜並點擊啟示來訪問，這時候每個應用程序旁邊都會有一個「停止」按鈕。

利用 JobScheler，應用可使用 JobInfo.Builder.setPrefetch() 將特定作業標記為「預提取」，這意味著理想情況下這些作業應該在應用下一次啟動前提前一點運行，以提升用戶體驗。

過去，JobScheler 僅使用該信號讓預提取作業有機會使用免費或多餘的數據，在 Android 13 中系統現在會嘗試確定應用下次啟動的時間，並根據該估算值運行預提取作業，應用應嘗試使用「預提取」來完成他們想要在下次應用啟動前完成的任何工作。

Android 13 中引入了 電池資源利用率 功能，以便為系統提供多種方法來更好地管理設備電池續航時間：

⑶ Android之隱藏api介紹

..

Android P 引入了針對非 SDK 介面（俗稱為隱藏API）的使用限制。這是繼 Android N上針對 NDK 中私有庫的鏈接限制之後的又一次重大調整。

從今以後，不論是native層的NDK還是 java層的SDK，我們只能使用Google提供的、公開的標准介面。這對開發者以及用戶乃至整個Android生態，當然是一件好事。

但這也同時意味著Android上的各種黑科技有可能會逐漸走向消亡。

公共 SDK 介面是在 Android 框架軟體包索引 中記錄的那些介面

從 Android Pie 開始，對某些隱藏類、方法和欄位的訪問受到限制在 Pie 之前，通過簡單地使用反射來使用這些隱藏的非 SDK 組件非常容易。

但是，現在當嘗試訪問時，面向 API 28 (Pie) 或更高版本的應用程序將遇到 ClassNotFoundException、NoSuchMethodError 或 NoSuchFieldException Activity#createDialog() 。

先來看看系統是如何實現這個限制的。

通過反射或者JNI訪問非公開介面時會觸發警告/異常等，那麼不妨跟蹤一下反射的流程，看看系統到底在哪一步做的限制。

先來看一下 java.lang.Class.getDeclaredMethod(String) ：

其中看一下 ShouldBlockAccessToMember 的調用，如果它返回false，那麼直接返回 nullptr ，上層就會拋 NoSuchMethodXXX 異常；也就觸發系統的限制了。

源碼如下：

繼續跟蹤下 GetMemberAction方法 ：

繼續跟蹤GetMemberActionImpl方法：

其中調用到了

只要 IsExempted 方法返回 true，就算這個方法在黑名單中，依然會被放行然後允許被調用。

IsExempted 方法：

繼續跟蹤傳遞進來的參數 runtime->GetHiddenApiExemptions() 發現也是 runtime 裡面的一個參數.

這樣就可以直接修改 hidden_api_exemptions_ 繞過去限制。

Java 層的，有一個對應的 VMRuntime.setHiddenApiExemptions 方法,通過 VMRuntime.setHiddenApiExemptions 設置下豁免條件，就能愉快滴使用反射了。

IsExempted 方法裡面調用 DoesPrefixMatch 方法。DoesPrefixMatch是對方法簽名進行前綴匹配。所有Java方法類的簽名都是以 L 開頭，這樣就可以直接傳個 L 進去，所有的隱藏API全部被赦免了！

另一種繞過 Android P以上非公開API限制的辦法

⑷ 如何理解android中的api level

就是安卓開發包的版本號，比如安卓4.0對應的level是14，5.0對應的level是19

⑸ api28是安卓什麼版本

api28每一個系統版本都對應一個編號的，21代表安卓5.0系統，23代表安卓6.0系統。

api28使用國內鏡像，鏡像地址在附件中埠80。使用工具進行連接；設置Eclipse的更新地址，將地址設置為本機8580；重新打開SDK Manager 將需要更新或者下載的選項勾上並按 Install Packages即可。

api28常見問題：

api28假設你想在你的窗體模塊中聲明一個函數，粘貼然後運行，VB會告訴你：編譯錯誤...Declare 語句不允許作為類或對象模塊中的Public(公共的) 成員。看起來很糟糕，其實你需要做的只是在聲明前面添加一個Private(私有的)。

api28可是這將使該函數只在該窗體模塊可用。在有些情況下，你會得到"不明確的名稱"這樣的提示，這是因為函數、常量或其他的什麼東西共用了一個名稱。

api28由於絕大多數的函數都進行了別名化，亦即意味著你可以通過Alias子句使用其它的而不是他們原有的名稱，你只需簡單地改變一下函數名稱而它仍然可以正常運行。

⑹ android引用API是不是需要先導入對應的jar包API與jar是什麼關系

API 是應用程序編程介面，是一些預先定義的類（java、class文件），我們寫程序的時候可以直接使用這些已經被打包（jar包）的類來做具體的應用。我們在搭建jdk開發環境的時候就包含了API。

⑺ Android SDK對應API級別以及版本說明

Android 11 (API 級別 30)

如需詳細了解平台變更，請參閱  Android 11 文檔 。

Android 10（API 級別 29）

如需詳細了解平台變更，請參閱 面向開發者的 Android 10 。

修訂版 5（2020 年 7 月）

此修訂版本添加了 Android Automotive OS 樁。

Android 9（API 級別 28）

如需詳細了解平台變更，請參閱 面向開發者的 Android 9 。

修訂版 1（2018 年 8 月）

已發布為穩定版（不再處於預覽狀態）。

Android 8.1（API 級別 27）

如需詳細了解平台變更，請參閱 面向開發者的 Android 8.1 。

修訂版 1（2017 年 12 月）

已發布為穩定版（不再處於預覽狀態）。

Android 8.0（API 級別 26）

如需詳細了解平台變更，請參閱 面向開發者的 Android 8.0 。

修訂版 2（2017 年 8 月）

Android 7.1（API 級別 25）

如需詳細了解平台變更，請參閱 面向開發者的 Android 7.1 。

修訂版 3（2016 年 12 月） 修訂版 2（2016 年 11 月） 修訂版 1（2016 年 10 月）

Android 7.0（API 級別 24）

如需詳細了解平台變更，請參閱 面向開發者的 Android 7.0 。

修訂版 1（2016 年 8 月）

Android 6.0（API 級別 23）

如需詳細了解平台變更，請參閱  Android 6.0 變更 和  Android 6.0 API 。

修訂版 2（2015 年 11 月） 修訂版 1（2015 年 8 月）

Android 5.1（API 級別 22）

如需詳細了解平台變更，請參閱  Lollipop 概覽 和  Android 5.1 API 變更 。

修訂版 1（2015 年 3 月）

Android 5.0（API 級別 21）

如需詳細了解平台變更，請參閱  Lollipop 概覽 和  Android 5.0 API 變更 。

修訂版 2（2014 年 12 月） 修訂版 1（2014 年 10 月）

Android 4.4W（API 級別 20）

此版本使 KitKat 支持 Android Wear。

修訂版 2（2014 年 10 月） 修訂版 1（2014 年 6 月）

Android 4.4（API 級別 19）

如需詳細了解平台變更，請參閱  KitKat 概覽 和  Android 4.4 API 變更 。

修訂版 2（2013 年 12 月） 修訂版 1（2013 年 10 月）

Android 4.3（API 級別 18）

如需詳細了解平台變更，請參閱  Jelly Bean 概覽 和  Android 4.3 API 變更 。

修訂版 2（2013 年 8 月） 修訂版 1（2013 年 7 月）

Android 4.2（API 級別 17）

如需詳細了解平台變更，請參閱  Jelly Bean 概覽 和  Android 4.2 API 變更 。

修訂版 2（2013 年 2 月） 修訂版 1（2012 年 11 月）

Android 4.1（API 級別 16）

如需詳細了解平台變更，請參閱  Jelly Bean 概覽 和  Android 4.1 API 變更 。

修訂版 3（2012 年 10 月） 修訂版 2（2012 年 7 月） 修訂版 1 （2012 年 6 月）

Android 4.0.3（API 級別 15）

修訂版 3（2012 年 3 月） 修訂版 2（2012 年 1 月） 修訂版 1（2011 年 12 月）

Android 4.0（API 級別 14）

Android 4.0，修訂版 2（2011 年 12 月） Android 4.0，修訂版 1（2011 年 10 月）

Android 3.2（API 級別 13）

Android 3.2，修訂版 1（2011 年 7 月）

Android 3.1（API 級別 12）

Android 3.1，修訂版 3（2011 年 7 月） Android 3.1，修訂版 2（2011 年 5 月） Android 3.1，修訂版 1（2011 年 5 月）

Android 3.0（API 級別 11）

Android 3.0，修訂版 2（2011 年 7 月） Android 3.0，修訂版 1（2011 年 2 月）

Android 2.3.3（API 級別 10）

Android 2.3.3，修訂版 2（2011 年 7 月） Android 2.3.3，修訂版 1（2011 年 2 月）

Android 2.3（API 級別 9）

Android 2.3，修訂版 1（2010 年 12 月）

授人以魚不如授人以漁

https://developer.android.com/studio/releases/platforms?hl=zh-cn

⑻ android 17是哪個版本

Android-17不是手機型號，是android的api版本，意思就是當前Android系統的版本是4.2.2
補充：
android系統版本對應的API定義就是andorid-X，其中X是數字。一個API版本對應一個系統版本。

⑼ android的sdk和api是什麼意思

SDK就是Kit，工具箱嘛，IOS平台上就是XCode，一系列的工具組合在一起，比如你在編輯器里敲代碼的時候它會自動補全代碼，自動錯誤檢查，你點一下Run，它會調用編譯器來自動編譯，編譯完它會調用iPhone的模擬器來運行，這就是SDK，提供整套的開發工具供開發者使用。
OpenAPI就是網站提供的介面，比如你想開發一個圍脖的手機客戶端，你從哪裡讀取數據寫入數據呢？總不能從Web版里調用吧？那裡是一堆一堆的html代碼啊，所以OpenAPI就是網站提供的介面，供開發者接入用的，比如聚合數據平台。

SDK (Software Development Kit)翻譯成中文就是"軟體開發工具組"
是用來幫一個 產品 或 平台 開發應用程式的工具組，由產品的廠商提供給開發者使用的。
通常是 某一家廠商 針對某一 平台 或 系統 或 硬體 所發布出來用以開發應用程式的工具組，
在這個工具包裡面，可能包含了各式各樣的開發工具，模擬器等。
例如：給 Android平台 使用的 Android SDK 就是用來開發 Android系統上面的應用程式。
API (Application Programming Interface)
翻譯成中文就是"應用程式介面"，其實這樣翻譯不好，應該說是"程式溝通介面"。
翻譯為介面，顧名思義就要溝通兩個不同的東西用的，通常由一組函式庫所組成。
在一個 同一個平台 下的 兩個不同東西(程式 or 系統)，為了能取用對方的功能等等，
所以一個 X程式 寫了一組函式，讓 同一平台的其他程式 取用 X程式 的功能，
那組函式就可以說是那個 X程式 對外開放的 API。
例如：我要在 自己的網頁 上加入 google map網頁的功能，就使用 "google map API"

有時候 SDK(開發者工具包) 里也會帶有些許 API 用來調用一些系統平台程式提供的功能
例如說：視窗顯示，圖形特效等等。
以下舉一個實際例子來說明，調用系統程式功能的API 是怎麽一回事
開發Windows應用程式的SDK(開發者工具包) 里就包含 Win32 API
說明： Win32 API 是一個函式庫，可以給Windows應用程式 調用 Windows系統的功能
在PTT看到有人問了差異性，我的看法是
SDK是用來開發某一個平台的程式的工具包，API 是讓同一平台下的程式取用它的功能的函式庫。
以及下面的評論
1.API 通常大家都不會弄錯，的確就是以功能為導向的"方法"或"函式"清單，
看程式語言或平台而定( Methods, Functions... )，
而每個 API 主要都是為了達成某特定功能所設計的。
開發商可以為了不同平台，設計相同的 API 讓開發者使用，
也可能會因應不同平台，製作不同的 API 讓開發者使用。
2.當 API 數量夠多功能夠繁復並且可交互為用的時候，
( 例如為了達成某些功能，常需要同時引用某些 APIs 來完成 )
開發商就會為了開發便利，而預先撰寫好一些組合好 APIs 的 API
供開發者使用，來統一有特定需求的開發者能有一致的開發與使用體驗，
( 例如讓使用"網路連線"的開發者不需自己處理網路的基礎溝通信息，
與錯誤處理方式，使 API 在應用的時候有一定程度的便利性等 )
然後，也陸續發展出測試、除錯工具，甚至是設計不同平台開發環境所需的套件，
尤其針對不同平台，更是設計了對應的工具來協助開發、除錯；
SDK 名詞之所以出現，儼然是為了匯整上述這些資源而誕生的，
我想也可以說成是 API 的包含者(直接使用)與應用者(以便加速開發)，
也因此可以說這兩個是屬於不同層級的東西...