安全要點
Android 操作系統內置了安全功能，可顯著降低應用出現安全問題的頻率及其造成的影響。系統經過精心設計，您在通常情況下只需使用默認的系統和文件權限即可打造自己的應用，而無需費心針對安全性作出艱難決策。
下面是一些可以幫助您打造安全應用的核心安全功能：
- Android 應用沙盒，可以將您的應用數據和代碼執行與其他應用分隔開來。
- 應用框架，可以穩健實現常見的安全性功能，例如加密、權限和安全 IPC。
- ASLR、NX、ProPolice、safe_iop、OpenBSD dlmalloc、OpenBSD calloc 和 Linux mmap_min_addr 等多項技術，可降低與常見內存管理錯誤相關的風險。
- 加密的文件系統，啓用後可保護丟失或被盜設備上的數據。
- 用戶授予的權限，可用來限制對系統功能和用戶數據的使用。
- 應用定義的權限，可針對各個應用分別控制應用數據。
不過，我們仍建議您熟悉一下本文檔中所述的 Android 安全性最佳做法。遵循這些最佳做法，養成常規編碼習慣，就可以有效減少因疏忽而引發安全問題的機率，防止對用戶產生不利的影響。
存儲數據
對於 Android 應用，最常見的安全問題就是其他應用能否訪問用戶保存在設備上的數據。下面介紹了將數據保存在設備上的三種基本方法：
使用內部存儲空間
默認情況下，您在內部存儲空間中創建的文件僅供您的應用訪問。這項保護措施由 Android 實現，而且這對於大多數應用來說足夠了。
一般情況下，建議您儘量避免將 MODE_WORLD_WRITEABLE 或 MODE_WORLD_READABLE 模式用於 IPC 文件，因爲在這兩種模式下，系統不提供針對特定應用限制數據訪問的功能，也不會對數據格式進行任何控制。如果您想與其他應用進程共享數據，不妨考慮使用內容提供程序，它可以爲其他應用提供讀取和寫入權限，還能針對各種具體情況授予動態權限。
要爲敏感數據提供額外的保護，您可以選擇使用該應用無法直接訪問的密鑰來對本地文件進行加密。例如，您可以將密鑰存儲在 KeyStore 中，並使用未存儲在相應設備上的用戶密碼加以保護。不過，如果攻擊者獲得超級用戶權限，就可以在用戶輸入密碼時進行監控，數據也就失去了這層保護屏障；但是，這種方式可以保護丟失設備上的數據，而無需進行文件系統加密。
使用外部存儲設備
在外部存儲設備（例如 SD 卡）上創建的文件不受任何讀取和寫入權限的限制。對於外部存儲設備中的內容，不僅用戶可以將其移除，而且任何應用都可以對其進行修改，因此最好不要使用外部存儲設備來存儲敏感信息。
就像處理來源不受信任的數據一樣，您應對外部存儲設備中的數據執行輸入驗證。強烈建議您不要在動態加載前將可執行文件或類文件存儲在外部存儲設備中。如果您的應用確實從外部存儲設備中檢索可執行文件，請在動態加載前對這些文件執行簽名和加密驗證。
使用內容提供程序
內容提供程序提供結構化存儲機制，可以將內容限制爲僅供自己的應用訪問，也可以將內容導出以供其他應用訪問。如果您不打算向其他應用授予訪問您的 ContentProvider 的權限，請在應用清單中將其標記爲 android:exported=false；要允許其他應用訪問存儲的數據，請將 android:exported 屬性設置爲 "true"。
在創建要導出以供其他應用使用的 ContentProvider 時，您可以在清單中指定允許讀取和寫入的單一權限，也可以針對讀取和寫入操作分別指定權限。我們建議您僅對需要完成相應任務的應用授予權限。請注意，與其移除權限而影響到現有用戶，不如以後要使用新功能時再添加權限。
如果您要使用內容提供程序僅在自己的應用之間共享數據，最好將 android:protectionLevel 屬性設置爲 "signature" 保護級別。簽名權限不需要用戶確認，因此，這種方式不僅能提升用戶體驗，而且在相關應用使用相同的密鑰進行簽名來訪問數據時，還能更好地控制對內容提供程序數據的訪問。
內容提供程序還可以通過以下方式提供更細化的訪問權限：聲明 android:grantUriPermissions 屬性，並使用用來啓動組件的 Intent 對象中的 FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 標記。使用 <grant-uri-permission
element> 還能進一步限制這些權限的範圍。
訪問內容提供程序時，請使用參數化的查詢方法（例如 query()、update() 和 delete()），以免產生來源不受信任的
SQL 注入風險。請注意，如果以組合用戶數據的方式構建 selection 參數，然後再將其提交至參數化方法，則使用參數化方法可能不夠安全。
請不要誤以爲提供寫入權限很安全。設想一下，寫入權限允許使用 SQL 語句，這使得攻擊者可以通過使用各種 WHERE 子句以及對相關結果進行解析來確認某些數據。例如，如果攻擊者想要探查通話記錄中是否存在某個特定電話號碼，只要該號碼已經存在，攻擊者就可以通過修改其中的一行來獲知。如果內容提供程序數據採用可預測的結構，那麼授予寫入權限相當於同時提供了讀取和寫入權限。
使用權限
由於 Android 通過沙盒機制管理各個應用，因此應用必須以明確的方式共享資源和數據。應用會通過聲明自己需要的權限來獲取基本沙盒未提供的額外功能（包括對相機等設備功能的訪問權限），從而實現這一點。
請求權限
我們建議您儘量減少應用請求的權限。如果不具備對敏感數據的訪問權限，就能降低不慎誤用這類權限的風險，並可提高用戶的採用率，同時讓您的應用不那麼容易受到攻擊者的攻擊。一般來說，如果您的應用無需某項權限也能正常運行，就不要請求該權限。
如果可以採用不需要任何權限的方式設計應用，建議採用這種方式。例如，與其請求訪問設備信息的權限以創建唯一標識符，不如爲您的應用創建一個 GUID（請參閱處理用戶數據的相關部分）。或者，您也可以不將數據存儲在外部存儲設備（需要請求權限），而將其存儲在內部存儲空間。
除了請求權限之外，您的應用也可以使用 <permissions> 來保護對安全性要求較高且會被其他應用訪問的
IPC，例如 ContentProvider。一般而言，我們建議您儘量使用訪問權限控制，而不使用需要用戶確認的權限，因爲權限管理對用戶來說可能比較複雜。例如，對於同一開發者提供的不同應用之間的
IPC 通信，不妨使用 "signature" 保護級別。
請勿泄露受權限保護的數據。當您的應用通過 IPC 傳輸數據時可能會出現泄漏，不過，只有您的應用擁有特定權限時，纔可能發生數據泄漏。應用 IPC 接口的客戶端可能沒有相同的數據訪問權限。要詳細瞭解潛在影響以及這類問題發生的頻率，請參閱在 USENIX 上發佈的這篇研究論文。
創建權限
一般來說，您應在滿足安全性要求的前提下儘可能少定義權限。對於大多數應用來說，它們很少會創建新權限，因爲系統定義的權限就能滿足大部分的需求。請視需要使用現有權限執行訪問權限檢查。
如果必須創建新權限，請儘量考慮創建 "signature" 保護級別的權限。“簽名”級別權限的內容對用戶完全透明開放，而且只有由執行權限檢查的應用的開發者簽名的應用纔可訪問這些內容。
如果您創建了 "dangerous" 保護級別的權限，則事情就會更加複雜，您需要注意：
- 該權限必須包含一個字符串，向用戶清楚明確地說明他們需要做出的安全決策。
- 該權限的字符串必須翻譯成多種不同語言。
- 用戶可能會因爲權限含糊不清或存在風險而選擇不安裝應用。
- 應用可能會在權限創建程序尚未安裝的情況下請求權限。
這些事情會給開發者帶來巨大的非技術性挑戰，也讓用戶感到困惑，因此我們不鼓勵使用 "dangerous" 權限級別。
使用網絡
網絡交易涉及傳輸對用戶而言可能比較私密的數據，因此本質上就存在安全風險。用戶開始逐漸意識到移動設備存在的隱私泄漏問題，尤其是在通過設備進行網絡交易時。因此，請務必對您的應用採取各種最佳做法，以始終確保用戶的數據安全。
使用 IP 網絡
Android 網絡運行機制與其他 Linux 環境差別不大，關鍵是確保對敏感數據使用合適的協議，如使用 HttpsURLConnection 來保證網絡流量安全。我們建議您在服務器支持
HTTPS 的情況下一律使用 HTTPS（而非 HTTP），因爲移動設備經常會連接到不安全的網絡（如公共 WLAN 熱點）。
您可以使用 SSLSocket 類輕鬆實現經過身份驗證和加密的套接字層通信。考慮到
Android 設備會頻繁使用 WLAN 連接到不安全的無線網絡，我們強烈建議所有通過網絡通信的應用使用安全的網絡。
我們發現有些應用使用 localhost 網絡端口處理敏感的 IPC。我們不建議採用這種方法，因爲設備上的其他應用也可以訪問這些接口。相反，您應該使用可通過 Service 等進行身份驗證的
Android IPC 機制。（綁定到 INADDR_ANY 比使用回送功能還要糟糕，因爲這樣一來，您的應用可能會收到任何位置發來的請求。）
此外，還有一個需要再三強調的常見問題就是，切勿相信通過 HTTP 或其他非安全協議下載的數據，包括 WebView 中的輸入驗證以及對通過
HTTP 發出的 intent 的任何響應。
使用電話網絡
短信 協議主要是爲用戶間通信設計的，並不適合要傳輸數據的應用。考慮到短信的侷限性，因此，想從網絡服務器向用戶設備上安裝的應用發送數據消息時，我們強烈建議您使用 Google 雲消息傳遞 (GCM) 和 IP 網絡。
請注意，短信在網絡上和設備上均未經過加密，也沒有經過嚴格的身份驗證。而且，短信的所有接收者都應明白，您的應用收到的短信可能來自惡意用戶。因此，切勿使用未經身份驗證的短信數據執行敏感命令。還需要注意的是，短信可能包含欺騙性內容，也有可能在網絡上傳輸時被攔截。在 Android 設備上，短信會以廣播 intent 的形式傳輸，因此可能會被其他擁有 READ_SMS 權限的應用讀取或捕獲。
執行輸入驗證
無論應用是在哪種平臺上運行，輸入驗證功能不完善都是影響應用的最常見安全問題。Android 爲此提供了平臺級對策，可降低應用出現輸入驗證問題的可能性。如果可行，請儘量使用這些功能。另請注意，選擇類型安全的語言通常也有助於降低出現輸入驗證問題的可能性。
如果使用原生代碼，那麼系統從文件讀取、通過網絡接收或從 IPC 接收的任何數據都有可能會引發安全問題。最常見的問題包括緩衝區溢出、釋放後重用和差一錯誤。Android 爲此提供了多項技術，例如 ASLR 和 DEP ，可以降低這些錯誤被利用的可能性，但無法解決根本問題。因此，請謹慎管理指針和緩衝區，預防這些漏洞造成破壞。
使用基於字符串的動態語言（如 JavaScript 和 SQL）也可能因爲轉義字符和腳本注入而出現輸入驗證問題。
如果使用提交到 SQL 數據庫或內容提供程序的查詢中的數據，也可能出現 SQL 注入問題。最好的預防措施是使用參數化查詢（請參閱上文內容提供程序部分的相關內容）。將權限限制爲只讀或只寫，也可以降低 SQL 注入引發破壞的可能性。
如果您無法使用上述安全功能，我們強烈建議您使用結構合理的數據格式，並驗證數據是否符合預期的格式。雖然將字符列入黑名單或替換字符是一種有效的策略，但這些技術在實際操作中很容易出錯，因此應儘量避免使用。
處理用戶數據
通常情況下，確保用戶數據安全的最佳做法是儘量避免使用會訪問用戶敏感數據或個人數據的 API。如果您擁有用戶數據的訪問權限，並且能夠避免存儲或傳輸這些信息，那麼就不要存儲或傳輸這些數據。最後，請評估您的應用邏輯能否使用經過哈希算法處理或不可逆的數據格式進行實現。例如，您的應用可能會使用電子郵件地址的哈希值作爲主要密鑰，以避免傳輸或存儲電子郵件地址。這樣可降低在無意之中泄露數據的可能性，還可以降低攻擊者嘗試利用您的應用搞破壞的可能性。
請注意，如果您的應用會訪問密碼或用戶名等個人信息，部分司法轄區可能會要求您提供隱私權政策，以說明您如何使用或存儲這類數據。因此，遵循安全最佳做法（即儘可能減少對用戶數據的訪問）也有助於簡化合規工作。
此外，您還應考慮自己的應用是否會在無意之中將個人信息泄露給其他方，如廣告使用的第三方組件或應用使用的第三方服務。如果不知道某個組件或服務爲什麼需要個人信息，就不要提供個人信息。通常，減少您的應用對個人信息的訪問，可以降低引發這方面問題的可能性。
如果必須訪問敏感數據，請判斷這些信息是必須傳輸至服務器，還是可以在客戶端上執行相應操作。建議您在客戶端上運行所有需要使用敏感數據的代碼，以避免傳輸用戶數據。
此外，請務必不要使用權限過於寬鬆的 IPC、完全沒有寫入限制的文件或網絡套接字，避免在無意之中將用戶數據泄露給設備上的其他應用。這屬於一種造成受權限保護的數據遭泄露的特殊情況，我們已在請求權限部分討論過。
如果需要 GUI ，請創建一個較長的具有唯一性的編號並加以存儲。請勿使用可能與個人信息關聯的電話標識符，如電話號碼或 IMEI。有關此主題的詳情，請參閱 Android 開發者博客。
向設備上的日誌寫入內容時，請務必謹慎小心。在 Android 中，日誌是共享資源，擁有 READ_LOGS 權限的所有應用均可訪問。即使電話日誌數據是臨時數據並會在重新啓動時清空，不當記錄用戶信息也可能在無意之中將用戶數據泄露給其他應用。
使用 WebView
由於 WebView 使用的網絡內容可能包含 HTML 和 JavaScript，當的使用可能引入常見的網絡安全問題，例如跨站腳本攻擊（JavaScript
注入）。Android 內置了多種機制，可將 WebView 的功能限制爲您應用所需的最低功能，以縮小這些潛在問題的影響範圍。
如果您的應用不直接使用 WebView 中的 JavaScript，請勿調用 setJavaScriptEnabled()。部分示例代碼會使用這種方法，不過您可能需要在實際應用時根據具體情況進行調整。因此，如果不需要使用這種調用方法，請將其移除。默認情況下，WebView 不會執行
JavaScript，因此不可能出現跨站腳本攻擊這樣的安全問題。
addJavaScriptInterface() 允許
JavaScript 調用正常情況下是爲 Android 應用預留的操作，因此在使用時請格外小心。如果要使用，請僅將 addJavaScriptInterface() 用於所有輸入內容都可信的網頁。如果您接受不受信任的輸入內容，那麼不受信任的
JavaScript 可能會調用您應用中的 Android 方法。一般情況下，我們建議您僅將 addJavaScriptInterface() 用於應用
APK 內含的 JavaScript。
如果您的應用通過 WebView 訪問敏感數據，您可能需要使用 clearCache() 方法來刪除本地存儲的所有文件。您也可以使用服務器端標頭（例如 no-cache）來指示應用不應緩存特定內容。
在 Android 4.4（API 級別 19）之前平臺上運行的設備使用的 webkit 版本存在多個安全問題。如果您的應用在這些設備上運行，解決方法是確認 WebView對象只顯示值得信任的內容。還應使用可更新的安全 Provider 對象確保您的應用在
SSL 中不會暴露給潛在的漏洞，如更新您的安全提供程序以防範 SSL 攻擊中所述。如果您的應用必須從開放網絡渲染內容，請考慮提供您自己的渲染程序，以便使用最新的安全補丁程序保持其處於最新狀態。
處理憑據
一般情況下，我們建議您儘量降低要求用戶憑據的頻率；這樣會讓釣魚攻擊顯得比較可疑，從而能夠降低其成功率。作爲替代方法，您可以使用授權令牌並根據需要刷新。
請儘量避免將用戶名和密碼存儲在設備上。您可以使用用戶提供的用戶名和密碼進行初始身份驗證，然後使用針對特定服務的短時效授權令牌。
可供多個應用訪問的服務應使用 AccountManager 進行訪問。如果可行，請使用 AccountManager 類來調用基於雲的服務；此外，請勿將密碼存儲在設備上。
使用 AccountManager 檢索 Account 後，請先確認 CREATOR 再傳送憑據，以免無意中將憑據傳送給錯誤的應用。
如果憑據僅供您創建的應用使用，那麼您可以使用 checkSignature() 驗證訪問 AccountManager 的應用。另外，如果只有一個應用使用該憑據，那麼您可以使用 KeyStore 存儲憑據。
使用加密
Android 不僅提供數據隔離機制、支持完整文件系統加密並提供安全通信通道，還提供大量使用加密來保護數據的算法。
一般情況下，請嘗試根據您的具體情況使用已經實現的最高級別的框架。如果您需要從某個已知位置安全地檢索文件，使用簡單的 HTTPS URI 即可滿足需要，無需具備加密知識。如果您需要一個安全通道，不妨考慮使用 HttpsURLConnection 或 SSLSocket，而無需自行編寫協議。
如果您需要實現自己的協議，我們強烈建議您不要實現自己的加密算法。請使用現有加密算法，例如 Cipher 類中提供的
AES 或 RSA 實現中的算法。
使用安全隨機數生成器 SecureRandom 初始化任意加密密鑰 KeyGenerator。如果使用的密鑰不是安全隨機數生成器生成的，那麼會顯著降低算法的強度，容易導致出現離線攻擊。
如果您需要存儲密鑰以供重複使用，請使用 KeyStore 等可以長期存儲和檢索加密密鑰的機制。
使用進程間通信
部分應用會嘗試使用傳統 Linux 技術（如網絡套接字和共享文件）來實現 IPC。強烈建議您改爲使用 Android 針對 IPC 提供的系統功能，例如使用 Service 的 Intent、Binder 或 Messenger，以及 BroadcastReceiver。Android
IPC 機制讓您驗證連接至 IPC 的應用的身份，併爲每種 IPC 機制設置安全策略。
許多安全元素在各種 IPC 機制之間是共享的。如果您的 IPC 機制並不打算讓其他應用使用，請在該組件的清單元素（例如 <service> 元素）中將 android:exported 屬性設置爲 "false"。對於同一
UID 中包含多項進程的應用，這種做法非常有用；當您在以後的開發過程中決定不以 IPC 的形式提供功能但又不想重新編寫代碼時，這樣做也會有所助益。
如果您的 IPC 預期供其他應用訪問，您可以使用 <permission> 元素應用安全策略。如果
IPC 是在您自己的不同應用（以同一密鑰登錄）之間使用，建議您在 android:protectionLevel 中使用 "signature" 級別權限。
使用 Intent
Intent 是 Android 中異步 IPC 的首選機制。根據您的應用要求，您可能會對特定的應用組件使用 sendBroadcast()、sendOrderedBroadcast() 或顯式
intent。
請注意，排序後的廣播可能會被接收者“佔用”，因此它們可能不會傳遞到所有應用。如果您要發送必須傳遞到特定接收者的 intent，那麼必須使用以 nameintent 聲明接收者的顯式 intent。
Intent 的發送器會驗證接收者是否有權通過方法調用來指定非空權限。只有具有該權限的應用纔會收到 intent。如果廣播 intent 中的數據屬於敏感數據，則不妨考慮應用相應權限，以確保惡意應用在沒有相應權限的情況下無法註冊以接收這些消息。在這些情況下，您還可以考慮直接調用接收器，而不是發起廣播。
注：請勿將 intent 過濾條件視爲安全功能 - 組件可通過顯式 intent 調用，但不一定擁有符合 intent 過濾條件的數據。您需要在 intent 接收器中執行輸入驗證，以確認 intent 的格式正確無誤，可用於調用的接收器、服務或 Activity。
使用服務
Service 通常用於提供其他應用要使用的功能。每個服務類在其清單文件中都必須有相應的 <service> 聲明。
默認情況下，服務不會被導出，而且無法由任何其他應用調用。不過，如果您將任何 intent 過濾條件添加到服務聲明中，那麼默認就會導出該服務。最好是明確聲明 android:exported 屬性，以確保其行爲符合您的需要。您也可以使用 android:permission 屬性來保護服務。這樣一來，其他應用只有在自己的清單中聲明相應的 <uses-permission> 元素，才能啓動、停止或綁定到服務。
服務可以先調用 checkCallingPermission()，然後再實現該調用，從而保護針對該服務、擁有相應權限的各個
IPC 調用。通常情況下，我們建議您在清單中使用聲明式權限，因爲這些權限不容易被忽略。
使用 Binder 和 Messenger 接口
使用 Binder 或 Messenger 是
Android 中 RPC 式 IPC 的首選機制。它們提供了定義完善的接口，可讓端點互相進行身份驗證（如果需要）。
我們強烈建議您在設計接口時，採取無需針對接口進行特定權限檢查的方式。應用清單中並未聲明 Binder 和 Messenger 對象，因此您無法向這些對象直接應用聲明式權限。一般情況下，如果您在 Service 或 Activity 中實現了這些對象，那麼它們會繼承
Service 或 Activity 的應用清單中聲明的權限。如果您要創建一個需要身份驗證和/或訪問控件的接口，則這些控件必須以代碼的形式明確添加到 Binder 或 Messenger 接口中。
如果您提供的接口確實需要訪問控件，請使用 checkCallingPermission() 驗證調用者是否具備所需權限。在代表調用者訪問服務前，請務必執行此操作，因爲您應用的身份會傳遞到其他接口。如果您調用的是 Service 提供的接口，在沒有訪問指定服務的權限的情況下，bindService() 調用可能會失敗。如果您調用的是自己的應用提供的本地接口，不妨使用 clearCallingIdentity() 來確保滿足內部安全檢查的要求。
如需瞭解有關通過服務執行 IPC 的詳細信息，請參閱綁定服務。
使用廣播接收器
BroadcastReceiver 會處理 Intent 發起的異步請求。
默認情況下，接收器會被導出，而且可以由任何其他應用調用。如果您的 BroadcastReceiver 預期供其他應用使用，您可能需要使用應用清單中的 <receiver> 元素向接收器應用安全權限。這樣可防止沒有相應權限的應用向 BroadcastReceiver 發送
intent。
動態加載代碼
我們強烈建議您不要從應用 APK 外部加載代碼。這樣做不僅會明顯加大應用因代碼注入或代碼篡改產生問題的可能性，還會增加版本管理和應用測試的難度。這最終會導致無法驗證應用的行爲，因此，某些環境中可能會禁止採用此做法。
如果您的應用會動態加載代碼，您務必謹記，運行動態加載的代碼需要擁有與應用 APK 相同的安全權限。用戶是因爲您才決定安裝您的應用的，因此他們希望您提供的是在您的應用內運行的代碼，包括動態加載的代碼。
與動態加載代碼相關的主要安全風險與這樣的代碼需要來自可驗證的來源有關。如果這些模塊已直接納入您的 APK 中，那麼其他應用就無法對其進行修改；無論代碼是原生庫代碼還是使用 DexClassLoader 加載的類，均是如此。我們見過很多應用嘗試從不安全的位置（例如，通過未加密的協議從網絡上進行下載）或任何人都可寫入內容的位置（如外部存儲設備）加載代碼的例子；對於前一種位置，網絡上的用戶將可以修改正在傳輸的內容，對於後一種位置，用戶設備上的其他應用將可以修改設備上的內容。
虛擬機中的安全性
Dalvik 是 Android 的運行時虛擬機 (VM)。雖然 Dalvik 是專爲 Android 而設計的，但是其他虛擬機中遇到的很多安全代碼問題在 Android 中也會出現。一般情況下，您無需擔心有關虛擬機的安全問題。您的應用在安全的沙盒環境中運行，因此係統中的其他進程無法訪問您的代碼或隱私數據。
如果希望深入瞭解虛擬機安全性，建議您研讀有關這方面的一些現有文獻。下面是兩種比較受歡迎的資源：
本文將重點說明 Android 特有或不同於其他虛擬機環境的方面。對於熟悉在其他環境中進行虛擬機編程的開發者，需要注意爲 Android 編寫應用的兩大不同之處：
- 有些虛擬機（例如 JVM 或 .net 運行時）會充當安全邊界，將代碼與基本操作系統功能分隔開來。在 Android 上，Dalvik 虛擬機不起安全邊界的作用 — 應用沙盒是在操作系統級別進行實現的，因此 Dalvik 可與同一應用中的原生代碼進行互操作，沒有安全限制。
- 鑑於移動設備上的存儲空間有限，開發者一般希望開發模塊化應用並使用動態類加載。這樣做時，請同時考慮您檢索應用邏輯的來源以及您在本地存儲應用邏輯的位置。請勿使用從未經驗證的來源（如不安全的網絡來源或外部存儲設備）加載的動態類，因爲這類代碼可能遭到篡改，從而執行某些惡意操作。
原生代碼中的安全性
一般情況下，我們鼓勵開發者使用 Android SDK 來開發應用，而不要使用 Android NDK 編寫原生代碼。通過原生代碼開發的應用比較複雜、可移植性較差，並且很可能會出現常見的內存損壞錯誤，如緩衝區溢出。
Android 使用 Linux 內核構建而成。如果您要使用原生代碼，熟悉一下 Linux 開發安全最佳做法會非常有用。本文中沒有介紹 Linux 安全做法，不過您可以查閱非常受歡迎的《Secure Programming for Linux and Unix HOWTO》，網址爲 http://www.dwheeler.com/secure-programs。
Android 與大多數 Linux 環境之間的一個重要區別在於應用沙盒。在 Android 上，所有應用都在應用沙盒中運行，包括那些採用原生代碼編寫的應用。對於熟悉 Linux 的開發者而言，其本質完全可以彙總成一句話：每個應用都被賦予唯一的 UID 和非常有限的權限。這樣就很好理解了。有關詳情，請參閱 Android 安全性概覽。此外，即使您使用的是原生代碼，也最好熟悉各種應用權限。