引言
轉自 Application developer best practies。部分內容有編輯。
正文
該文檔包含應用程序開發人員的最佳實踐，以幫助你為Android用戶和設備開發和釋放安全的應用程序。最佳實踐涵蓋四個方面：
1.系統安全：確保核心操作系統的安全性
2.應用安全：確保應用的安全性
3.網絡安全：確保網絡通信的安全
4.隱私：允許用戶控制數據的處理
系統安全
本節包含確保核心Android操作系統安全性的建議。
Biometric authentication
一定要小心謹慎地處理用于用戶認證的生物認證數據。從Android 9.0開始，應用程序可以利用新的BiometricPrompt API。支持在Android 8.1和更早的設備上使用support library的方式集成使用。Android 9.0 CDD中包含關于生物認證的更詳細和明確的要求。
后門
Android應用程序不應該有任何后門或方法繞過正常安全機制來訪問系統或數據。為了防止后門，有以下可以做的：
1.使用行業認可的應用程序漏洞掃描工具來掃描應用程序所使用的所有第三方庫和組件。您對應用程序中所有第三方組件的行為負責。
2.上傳應用程序到google play掃描，然后使用google play保護。您可以上傳應用程序而不發布。
設備驅動程序訪問
只有可信代碼才有直接訪問設備驅動程序的權限。
首選架構是提供一個單用途守護進程，該守護進程代理對驅動程序的調用并限制驅動程序對該守護進程的訪問。確保驅動設備節點不是全局可讀的或可寫的。CTS包括檢查暴露的驅動程序實例的測試。
應用安全
本節包含確保應用程序安全性的建議。
源碼審查
源代碼審查可以檢測廣泛的安全問題。Android大力鼓勵手動和自動源代碼審查。
1.在所有使用Android SDK的應用程序代碼上運行Android Link，并糾正所有被標識的問題。
2.應該使用能夠檢測內存管理問題（如buffer overflows和off-by-one errors）的自動化工具分析native code。
3.Android系統支持許多LLVM消毒器，例如AddressSanitizer和UndefinedBehaviorSanitizer，它們可用于內存相關問題的運行時分析。所有消毒器都應該打開，除非有明確的理由。在Android中通過libFuzzer結合fuzzing，可以發現需要進一步調查的不尋常的邊緣情況。
應用權限
因為Android應用程序彼此之間隔離。應用程序必須明確地共享資源和數據，需要通過聲明基本類型未提供的額外功能所需的權限來實現這一點，包括訪問諸如照相機之類的設備特性。
請求權限
您應盡量減少應用程序請求的權限數量。減少對敏感權限的訪問降低了無意中濫用這些權限的風險，提高了用戶的使用率，并使應用程序不易受到攻擊。一般來說，如果一個權限不是必須的，請不要請求它。如果有一個功能必須使用某個權限，否則應用程序不能運行，請使用清單文件中的元素聲明它。嘗試以不需要任何權限的方式設計應用程序。下面是一些例子：
1.為您的應用程序創建一個GUID，而不是請求訪問設備信息來創建唯一的標識符。有關的詳細信息，請參閱Handling user data
2.使用getExternalFilesDir將數據存儲在內部存儲器或應用程序的專用外部存儲器中，而不是使用需要權限的外部存儲器
3.使用標準Intent來避免請求權限。例如，使用ACTION_IMAGE_CAPTURE而不是持有camera的權限，使用ACTION_CALL而不是持有phone的權限。
除了請求權限之外，您的應用程序還可以使用清單中的element來保護暴露給其他應用程序并對安全性敏感的IPC，例如ContentProvider。一般來說，我們建議盡可能使用訪問控制而不是讓用戶確認權限，因為權限可能讓用戶感到困惑。例如，考慮使用Android提供的特定選擇器對話框進行單個元素訪問，或者，如果需要更廣泛的訪問，單個開發人員提供的多個應用程序之間的IPC通信權限上，可以考慮使用簽名保護級別。
不要泄漏受權限保護的數據。當應用程序通過IPC暴露數據時，這就會發生。因為您的應用程序具有訪問IPC的權限。應用程序的IPC接口的客戶端可能沒有相同的數據訪問權限。關于這個問題的頻率和潛在影響的更多細節出現在USENIX發表的研究論文《Permission Re-Delegation: Attacks and Defenses》中。
創建權限
盡量在滿足安全要求的同時定義盡可能少的權限。對于大多數應用程序來說，創建新權限相對來說并不常見，因為系統定義的權限覆蓋了許多情況。在合適的情況下，使用現有權限執行訪問檢查。如果必須創建新的權限，請考慮是否可以用簽名保護級別來完善。簽名權限對用戶是透明的，并且只允許由與執行權限檢查的應用程序相同簽名的應用程序訪問。如果仍然需要新的權限，則使用標簽在應用程序清單中聲明。希望使用新權限的應用程序可以通過在各自的清單文件中添加一個標簽來引用它。
如果你創建的是危險權限，則需要考慮的復雜性有很多：1.權限必須有一個字符串，該字符串簡潔地向用戶表達他們做出的安全決策。
2.權限字符串必須本地化到許多不同的語言。
3.應用程序可能在未安裝權限的創建者時請求權限。
所有這些都對作為開發人員的您提出了重大的非技術挑戰，同時這也使您的用戶感到困惑，這就是為什么我們不鼓勵使用危險權限。
數據存儲
Android上應用程序最常見的安全問題是，您保存在設備上的數據是否可被其他應用程序訪問。在設備上保存數據有三種基本方法：
1.Internal storage
2.External storage
3.Content providers
Internal storage
默認情況下，在內部存儲中創建的文件只能應用程序自身訪問。Android實現了這種保護，這對大多數應用程序來說都是足夠的。
一般來說，避免IPC文件的MODE_WORLD_WRITEABLE或MODE_WORLD_READABLE模式，因為它們不提供限制對特定應用程序的數據訪問的能力，也不提供數據格式的任何控制。如果希望與其他應用程序進程共享數據，可以考慮使用content provider，它為其他應用程序提供讀寫權限，并且可以根據具體情況動態授予權限。
為了對敏感數據提供額外的保護，可以使用應用程序不能直接訪問的密鑰對本地文件進行加密。例如，可以將密鑰放在密鑰存儲庫中，并用未存儲在設備上的用戶密碼來保護密鑰。雖然這不能保護數據免遭可能監視用戶輸入密碼的根本危害，但是它可以在沒有文件系統加密的情況下為丟失的設備提供保護。還可以使用StorageManager.isEncrypted()來確定文件路徑是否已經被系統加密，以避免雙重加密的性能開銷。
External storage
在外部存儲（例如SD卡）上創建的文件是全局可讀和可寫的。因為外部存儲可以由用戶移除，也可以由任何應用程序修改，所以不要使用外部存儲來存儲敏感信息。
在處理來自外部存儲的數據時，您應該執行輸入驗證，就像從任何不受信任的源中獲取數據一樣。在動態加載之前，不應將可執行文件或類文件存儲在外部存儲中。如果您的應用程序確實從外部存儲中檢索可執行文件，那么在動態加載之前，應該對文件進行簽名和加密驗證。
Content providers
Content providers提供了一個結構化的存儲機制，可以只限于您自己的應用程序，也可以暴露出來以允許其他應用程序訪問。如果不打算為其他應用程序提供對ContentProvider的訪問，請在應用程序清單中將它們標記為android:export=false。否則，將Android導出屬性設置為true，以允許其他應用程序訪問存儲的數據。
創建供其他應用程序使用的ContentProvider時，可以指定單個讀寫權限，也可以指定不同的讀寫權限。您應該將權限限制在完成手頭任務所需的權限上。請記住，稍后添加權限以公開新功能通常比取消權限并影響現有用戶更容易。
如果使用Content providers僅在自己的應用程序之間共享數據，則最好使用android:protectionLevel屬性設置簽名保護。簽名權限不需要用戶確認，因此當訪問數據的應用程序使用相同的密鑰簽名時，它們能提供更好的用戶體驗和更加受控的對內容提供商數據的訪問。
Content providers還可以通過聲明android:grantUriPermissions屬性并在激活組件的Intent對象中使用FLAG_GRANT_READ_URI_PERMIS.和FLAG_GRANT_WRITE_URI_PERMIS標志來提供更細粒度的訪問。這些權限的范圍可以進一步受標簽限制。
訪問Content providers時，選擇參數始終過濾不可信輸入，以避免可能的SQL注入攻擊。在實現內容提供程序時，始終使用啟用了setStrict()的SQLITQueryBuilder構造查詢，以防止SQL注入攻擊。
不要對寫權限有錯誤的安全感。寫權限允許SQL語句，這些語句允許使用創造性WHERE子句和解析結果來確認某些數據。例如，攻擊者可以通過僅在電話號碼已經存在的情況下修改一行來探測呼叫日志中特定電話號碼的存在。如果Content provider數據具有可預測的結構，則寫入權限可以等效于同時提供讀取和寫入。
輸入驗證
輸入驗證不足是影響應用程序的最常見安全問題之一，無論它們運行在什么平臺上。Android有平臺級別的對策，可以減少應用程序對輸入驗證問題的暴露，您應該盡可能使用這些特性。還要注意，類型安全語言的選擇往往會降低輸入驗證問題的可能性。
如果使用native code，則從文件讀取、通過網絡接收或從IPC接收的任何數據都有可能引入安全問題。最常見的問題是緩沖區溢出、釋放后使用和off-by-one錯誤。Android提供了許多技術，如ASLR和DEP，它們降低了這些錯誤的可利用性，但是它們并不能解決根本問題。通過仔細處理指針和管理緩沖區，可以防止這些漏洞。
基于字符串的動態語言，如JavaScript和SQL，由于轉義字符和腳本注入，也會遇到輸入驗證問題。
如果您正在使用的數據包含提交給SQL數據庫或內容提供者的查詢，SQL注入可能是一個問題。最好的防御是使用參數化查詢，正如上面關于Content providers的討論中所討論的。將權限限制為只讀或只寫也可以減少與SQL注入有關的危害。
如果不能使用上述安全特性，則應確保使用結構良好的數據格式，并驗證數據是否符合預期格式。雖然黑名單字符或字符替換可以是一個有效的策略，但這些技術在實踐中容易出錯，應該盡可能避免。
動態代碼加載
我們強烈反對從應用程序APK外部加載代碼。這樣做顯著地增加了由于代碼注入或代碼篡改導致的APP妥協的可能性。它還增加了版本管理和應用程序測試的復雜性。會使得無法驗證應用程序的行為，因此在某些環境中它可能被禁止。
如果您的應用程序確實動態加載代碼，那么關于動態加載的代碼，要記住的最重要的事情是它以與應用程序APK相同的安全權限運行。用戶根據您的身份決定安裝應用程序，并且用戶希望您提供的任何代碼，包括動態加載的代碼，在該應用程序中運行。
與動態加載代碼相關的主要安全風險是代碼需要來自可驗證的源。如果模塊直接包含在您的APK中，則它們不能被其他應用程序修改。無論代碼是本地庫還是使用DexClassLoader加載的類，都是如此。許多應用程序試圖從不安全的位置加載代碼，例如通過未加密協議從網絡下載，或者從外部存儲等可寫位置下載代碼。這些位置可以允許網絡上的人修改傳輸中的內容，或者允許用戶設備上的其他應用程序修改設備上的內容。
Native code
一般來說，您應該使用Android SDK進行應用程序開發，而不是使用Android NDK使用native code。使用本機代碼構建的應用程序更復雜、可移植性更差，并且更可能包含常見的內存損壞錯誤，例如緩沖區溢出。
Android是使用Linux內核構建的，如果您使用native code，那么熟悉Linux開發安全最佳實踐尤其有用。Linux的安全實踐超出了本文的范圍，但是最受歡迎的資源之一是Secure Programming HOWTO - Creating Secure Software。
Android和大多數Linux環境之間的一個重要區別是應用沙盒。在Android上，所有應用程序都運行在應用程序沙箱中，包括那些用native code編寫的應用程序。從最基本的層面來看，對于熟悉Linux的開發人員來說，考慮它的一個好方法就是知道每個應用程序都被賦予了具有非常有限的權限的惟一UID。Android Security Overview對此進行了更詳細的討論，您應該熟悉應用程序權限，即使您正在使用native code。
虛擬機
Dalvik是Android的運行時虛擬機（VM）。Dalvik是專門為Android構建的，但是關于其他虛擬機中安全代碼的許多關系也適用于Android。一般來說，您不應該擔心與虛擬機有關的安全問題。您的應用程序運行在安全沙箱環境中，因此系統上的其他進程無法訪問您的代碼或私有數據。
如果您對學習更多有關虛擬機安全性的知識感興趣，請熟悉一些關于這個主題的現有文獻。兩個比較受歡迎的資源是：
Securing Java
Related third-party projects
本文檔著聚焦于Android的特性或不同于其他VM環境的部分。對于在其他環境中具有VM編程經驗的開發人員來說，在為Android編寫應用程序時，存在兩個大問題：
一些虛擬機，例如JVM或.NET運行時，充當安全邊界，將代碼與底層操作系統功能隔離。在Android上，Dalvik VM不是一個安全邊界——Application Sandbox是在OS級別實現的，因此Dalvik可以在沒有任何安全約束的情況下與相同應用程序中的native code進行互操作。
由于移動設備上的存儲空間有限，開發人員通常希望構建模塊化應用程序并使用動態類加載。這樣做時，要考慮在哪里檢索應用程序邏輯以及在本地存儲它。不要使用來自未驗證的源（例如不安全的網絡源或外部存儲）的動態類加載，因為該代碼可能被加入惡意的行為。
應用發布
Google play提供了在不執行完整系統更新的情況下更新應用程序的能力。這可以加快對安全問題的響應和新特性的交付，同時也確保應用程序具有唯一包名的方法。
1.上傳你的應用程序到Google play，以允許自動更新，而不需要一個完整的空中（OTA）更新。上載但未發布的應用程序不能直接由用戶下載，但Google play上的應用程序仍然被更新。先前安裝應用程序的用戶可以重新安裝或安裝在其他設備上。
2.創建一個與你的公司有關聯的應用程序包名稱，例如使用公司商標。
應用簽名
App簽名在設備安全中起著重要的作用，也用于權限檢查以及軟件更新。在選擇用于簽署應用程序的密鑰時，考慮應用程序是否只在單個設備上使用還是在多個設備上通用是很重要的。
1.應用程序不能用公開的密鑰簽署。
2.用于簽署應用程序的密鑰應當以與處理敏感密鑰的行業標準實踐相一致的方式進行管理，包括提供有限、可審計訪問的HSM。
3.應用程序不應用平臺密鑰進行簽名。否則會讓應用程序擁有訪問平臺的簽名權限，這些權限非常強大，并且僅供操作系統的組件使用。如果你有比普通應用程序更需要特權的應用程序，你可以把它們變成一個特權應用程序。請確保使用白名單鎖定特權應用程序權限。
4.如果您用Google托管您的APK簽名密鑰，并且您的上傳密鑰丟失或受損，那么您可以與Google聯系以撤銷舊的上傳密鑰并生成新的密鑰。這只適用于Google play上的應用程序。
5.同一個包名的應用程序不應該用不同的密鑰簽名。這經常發生在為不同設備創建應用程序時，尤其是在使用平臺密鑰時。如果應用程序是獨立于設備的，則在設備上使用相同的密鑰。如果應用程序是特定于設備的，則在每個設備和密鑰上創建唯一的包名。
網絡安全
本節包含確保網絡通信安全的建議。
網絡
網絡事務本質上存在安全風險，因為它們涉及向用戶傳輸可能私有的數據。所有到目的地的網絡連接都應該被正確地加密，以防止在途中竊聽和修改，無論連接的內容如何，這都是真理。詳情請參閱我們的開發者峰會。
IP網絡
Android上的網絡與其他Linux環境沒有明顯不同。關鍵的考慮是確保使用適當的協議，例如用于安全通信的HttpsURLConnection 。考慮到Android設備與潛在的惡意無線網絡（例如不安全的Wi-Fi網絡）連接的頻率，強烈鼓勵所有通過網絡進行通信的應用程序使用安全網絡。至于Android P，默認情況下，嘗試使用未加密的連接將導致IOException。
可以使用SSLSocket類實現經過身份驗證的、加密的套接字級通信，但是正確驗證服務器證書的主機名與目的地匹配是至關重要的，因為SSLSocket在默認情況下不這樣做，這可以使用HttpsUrlConnection.getDefaultHostnameVerifier的標準HostnameVerifier來完成。
有些應用程序使用本地主機網絡端口來處理敏感的IPC，這是不安全的，不能使用。這是因為這些接口可以由設備上的其他應用程序訪問。相反，使用Android IPC機制，在那里可以進行身份驗證，例如使用服務。綁定到INADDR_ANY比使用回環更糟糕，因為您的應用程序可以從任何地方接收請求。
不要盲目信任來自遠程源的數據，特別是如果數據是通過HTTP或其他不安全協議傳遞的。這還包括在WebView中驗證輸入。
電話網絡
SMS協議主要是為用戶通信設計的，并不適合希望傳輸數據的應用程序。由于SMS的限制，您應該使用Firebase Cloud Messaging (FCM)和IP網絡將數據消息從Web服務器發送到用戶設備上的應用程序。
當心SMS既不加密也不在網絡或設備上進行強認證。特別是，任何SMS接收器都應該預期惡意用戶可能已經將SMS發送到您的應用程序。不要依賴未經認證的SMS數據來執行敏感命令或向設備傳送敏感數據。此外，您應該知道，SMS可能會受到網絡上的欺騙和/或攔截。在Android驅動的設備本身上，SMS消息作為廣播意圖傳輸，因此它們可以被具有READ_SMS權限的其他應用程序讀取或捕獲。
進程間通信
一些應用程序試圖使用傳統的Linux技術（如網絡套接字和共享文件）來實現IPC。但是，您應該使用Android系統功能來IPC，比如Intent、Binder或Messenger with Service，以及BroadcastReceiver。Android IPC機制允許您驗證連接到IPC的應用程序的身份，并為每個IPC機制設置安全策略。
許多安全元素在IPC機制之間共享。如果IPC機制不打算供其他應用程序使用，則在組件的manifest元素中將android:export屬性設置為false。這對于在同一UID中由多個進程組成的應用程序非常有用，或者如果您在開發后期決定不將功能公開為IPC，但是您不想重寫代碼。
如果您的IPC對于其他應用程序是可訪問的，您可以通過使用該元素來應用安全策略。如果IPC是在您自己的使用相同密鑰簽名的獨立應用程序之間，那么最好在android:protectionLevel中使用簽名級別權限。
使用intents
對于activities和broadcast receivers，intents是Android中異步IPC的首選機制。根據您的應用程序需求，您可以使用sendBroadcast()、sendOrderedBroadcast()或明確intents發送給特定應用程序組件。出于安全目的，首選的是明確的intent。
注意：如果使用intent綁定到服務，請確保使用明確的intent的應用程序是安全的。使用隱式intents啟動服務是一種安全隱患，因為您不能確定什么服務將響應該意圖，并且用戶無法看到哪個服務啟動。從Android 5.0開始（API級別21），如果你用一個隱式的intent調用bdIdService（），系統會拋出一個異常。
請注意，有序廣播可以由接收者使用，因此它們可能不會被傳遞到所有應用程序。如果發送的intent必須傳遞給特定的接收方，則必須使用通過名稱聲明接收方的顯式intent。
intent的發送者可以通過使用方法調用指定非空權限來驗證收件人是否具有權限。只有具有該權限的應用程序才接收到該intent。如果廣播意圖內的數據可能是敏感的，則應考慮應用權限以確保惡意應用程序在沒有適當權限的情況下不能注冊以接收這些消息。在這種情況下，您也可以考慮直接調用接收方，而不是發送廣播。
intent過濾器不應被認為是安全特性。組件可以用顯式intent調用，并且可能沒有符合intent過濾器的數據。為了確認它為被調用的接收機、服務或活動進行了適當的格式化，請在intent接收機內執行輸入驗證。
使用services
服務通常用于提供其他應用程序使用的功能。每個服務類必須在其清單文件中有一個相應的聲明。
默認情況下，服務不會暴露，不能被任何其他應用程序調用。但是，如果向服務聲明添加任何intent篩選器，則默認情況下暴露。最好是顯式聲明android:exported屬性，以確保它的行為符合你的意愿。服務也可以使用android:permission屬性來保護。通過這樣做，其他應用程序需要在自己的清單中聲明相應的元素，以便能夠啟動、停止或綁定到服務。
提示：如果應用程序針對Android 5.0（API級別21）或更高版本，則應該使用JobScheduler來執行后臺服務。有關JobScheduler的更多信息，請參見其API參考文檔。
服務可以通過在執行調用實現之前調用checkCallingPermission()來保護具有權限的單個IPC調用。您應該使用清單中聲明的權限，因為那些不太容易被疏忽。
注意：不要混淆客戶端和服務器權限；確保被調用的應用程序具有適當的權限，并驗證是否向調用的應用程序授予了相同的權限。
使用binder和messenger接口
使用binder或Messenger是Android中 RPC-style IPC的首選機制。它們提供了一個定義良好的接口，如果需要的話，可以實現端點的相互認證。
您應該以不需要特定于接口的權限檢查的方式設計應用程序接口。 Binder and Messenger沒有在應用程序清單中聲明，因此您不能直接向它們應用聲明性權限。它們通常繼承實現它們的Service或Activity的應用程序清單中聲明的權限。如果正在創建需要身份驗證或訪問控制的接口，則必須顯式地將這些控件作為代碼添加到Binder或Messenger接口中。
如果提供的接口確實需要訪問控制，則使用checkCallingPermission()來驗證調用方是否具有所需的權限。在代表調用者訪問服務之前，這一點特別重要，因為應用程序的標識被傳遞到其他接口。如果正在調用服務提供的接口，當沒有權限訪問給定服務時，則bindService()調用可能會失敗。如果調用您自己的應用程序在本地提供的接口，那么使用clearCallingIdentity()方法滿足內部安全檢查可能是有用的，該方法將調用者權限屏蔽為應用程序的權限。您可以通過使用RealCeCalpIdItId（）方法來恢復調用方權限。
有關使用服務執行IPC的更多信息，請參見綁定服務。
使用廣播接收器
廣播接收器處理intent發起的異步請求。
默認情況下，接收器被暴露并可以被任何其他應用程序調用。如果BroadcastReceiver打算供其他應用程序使用，你需要在應用清單中聲明安全權限。這阻止了沒有適當權限的應用程序向廣播接收器發送意圖。
安全監聽套接字
監聽套接字應該謹慎使用，并且通常不應該有任何開放式監聽套接字被Android應用程序暴露。
在沒有空中（OTA）更新的情況下，監聽套接字必須能夠被禁用。這可以使用服務器或用戶設備配置更改來執行。
對于使用套接字的本地IPC，應用程序必須使用UNIX域套接字，其訪問權限僅限于組。為IPC創建文件描述符，并為特定UNIX組生成+RW。任何客戶端應用程序必須在UNIX組內。
具有多個處理器（例如，與應用程序處理器分離的無線電/調制解調器）的一些設備使用網絡套接字在處理器之間進行通信。在這種情況下，用于處理器間通信的網絡套接字必須使用隔離的網絡接口來防止設備上的未經授權的應用程序訪問（即，使用iptables來防止設備上的其他應用程序訪問）。
處理偵聽端口的守護進程必須對錯誤的數據保持健壯性。谷歌可以使用未經授權的客戶端對端口進行模糊測試，并且在可能的情況下，授權客戶端。任何崩潰都將被歸類為錯誤的嚴重程度。
CTS包括檢查是否存在打開監聽端口的測試。
WebView
因為WebView使用包括HTML和JavaScript的web內容，所以不恰當的使用可能會引入常見的web安全問題，比如跨站點腳本（JavaScript注入）。Android包括許多機制，通過將WebView的能力限制到應用程序所需的最小功能來減少這些潛在問題的范圍。
如果您的應用程序在WebVIEW中不直接使用JavaScript，請不要調用StjJavaSpRIPabDebug（）。一些示例代碼使用此方法，您可能會在生產應用程序中重新使用它，因此如果不需要，請刪除該方法調用。默認情況下，WebView不執行JavaScript，因此跨站點腳本是不可能的。
特別小心使用addJavaScriptInterface()，因為它允許JavaScript調用通常為Android應用程序保留的操作。如果使用它，只將AdjJavaScript接口（）公開到所有輸入都值得信任的網頁。如果允許不受信任的輸入，不可信的JavaScript可以在應用程序中調用Android方法。一般來說，我們建議將AdjJavaScript接口（）僅暴露在應用程序APK內的JavaScript中。
如果應用程序使用WebView訪問敏感數據，則可能希望使用clearCache()方法刪除本地存儲的任何文件。還可以使用服務器端頭（如無緩存）來指示應用程序不應該緩存特定的內容。
為了確保您的應用程序沒有暴露SSL中的潛在漏洞，請使用可更新的安全提供程序對象，如更新您的安全提供程序以防止SSL漏洞。
憑證處理
為了使釣魚攻擊更加明顯，并且不太可能成功，請最小化請求用戶憑證的頻率。相反，使用授權令牌并刷新它。
在可能的情況下，不要在設備上存儲用戶名和密碼。相反，使用用戶提供的用戶名和密碼執行初始身份驗證，然后使用短期的、特定于服務的授權令牌。
可以使用Access管理器訪問多個應用程序可訪問的服務。如果可能的話，使用ActualMe管管理類調用基于云的服務，不要在設備上存儲密碼。
在使用AccountManager檢索帳戶之后，在傳遞任何憑據之前使用CREATOR，這樣就不會無意中將憑據傳遞給錯誤的應用程序。
如果憑證僅由您創建的應用程序使用，則可以使用checkSignature()驗證訪問AccountManager的應用程序。或者，如果只有一個應用程序使用憑據，則可以使用密鑰庫進行存儲。
隱私
本節包含確保Android用戶對數據的處理有控制權的建議
處理用戶數據
通常，用戶數據安全的最佳方法是最小化日志記錄和訪問敏感或個人用戶數據的API的使用。如果您可以訪問用戶數據，并且可以避免存儲或傳輸，則不要存儲或傳輸數據。考慮使用散列或其他不可逆形式的數據來實現邏輯。例如，您的應用程序可能使用電子郵件地址的不可逆散列作為主鍵，以避免發送或存儲電子郵件地址。這減少了無意中暴露數據的機會，也減少了攻擊者試圖利用您的應用程序的機會。
如果您的應用程序訪問個人信息，如密碼或用戶名，請記住，一些司法管轄區可能要求您提供隱私政策，解釋您使用和存儲這些數據。遵循安全性的最佳做法，最大限度地減少對用戶數據的訪問也可以簡化依從性。
您還應該考慮您的應用程序是否可能無意中將個人信息暴露給其他方，例如用于廣告的第三方組件或應用程序使用的第三方服務。如果你不知道為什么一個組件或服務需要個人信息，不要提供它。一般來說，減少應用程序對個人信息的訪問減少了該領域的潛在問題。
如果應用程序需要訪問敏感數據，請評估是否需要將其發送到服務器或是否可以在客戶端上運行該操作。只要可能，使用客戶端上的敏感數據運行任何代碼，以避免發送用戶數據。此外，請確保您不會無意中通過過度許可的IPC、可寫文件或網絡套接字將用戶數據暴露到設備上的其他應用程序。過度許可的IPC是泄漏許可保護數據的特殊情況，在請求權限部分中討論。
如果需要一個GUID，則創建一個大的、唯一的數字并存儲它。不要使用電話標識符，如電話號碼或IMEI，這是個人可識別的。本主題將在Android開發者博客中詳細討論。
在寫入設備日志時要小心。在Android中，日志是一個共享資源，擁有READ_LOGS權限的應用程序可以訪問它。盡管電話日志數據是臨時的，并且在重新啟動時擦除，但是用戶信息的不當日志記錄可能無意中將用戶數據泄露給其他應用程序。除了不記錄PII，生產應用程序應該限制日志使用。為了方便地實現這一點，使用調試標志和自定義日志類具有易于配置的日志記錄級別。
Logging數據
Logging數據增加了暴露該數據的風險，并降低了系統性能。由于敏感用戶數據的記錄，發生了多起公共安全事件。
應用程序不應記錄可能包含敏感信息的第三方應用程序提供的數據。
除非絕對需要提供應用程序的核心功能，否則應用程序不能將任何個人可識別信息（PII）作為正常操作的一部分進行日志記錄。
CTS包括檢查日志中是否存在潛在敏感信息的測試。
Metrics收集
確保Android應用程序中任何度量集合的最佳實踐是很重要的，包括：
確保未經明確、知情和有意義的用戶同意，不收集和報告Metrics標準。
除了少數例外，僅收集支持服務可靠性所必需的Metrics。
避免盡可能收集可識別或潛在敏感的數據，如硬件標識符。
盡可能確保數據足夠的聚集和匿名。
