僞加密
僞加密是Android4.2.x系統發佈前的加密方式之一，通過java代碼對APK(壓縮文件)進行僞加密，其修改原理是修改連續4位字節標記爲”P K 01 02”的後第5位字節，奇數表示不加密偶數表示加密。
雖然僞加密可以起到一定防破解作用，但也會出現問題，首先使用僞加密對其APK加密後市場無法對其進行安全檢測，導致部分市場會拒絕這類APK上傳；其次，僞加密的加密方式和解密方式也早已公佈導致它的安全程度也大大降低；再次，Android4.2.x系統無法安裝僞加密的APK；最後僞加密只是對APK做簡單保護，在java層源碼加殼保護、核心so庫、資源文件、主配文件、第三方架包方面卻沒有任何保護處理。注意：高版本不支持這樣的方法，所以還是不要嘗試使用這樣的加密方式了。
混淆保護
把原來有具體含義的類名，變量名，方法名，修改成讓人看不懂的名字。
運行時驗證
運行時驗證，主要是指在代碼啓動的時候本地獲取簽名信息然後對簽名信息進行檢驗來判斷自己的應用是否是正版，如果簽名信息不是正版則提示盜版或者直接崩潰。當然你可以把必要的數據放在服務器端。
破解：找到smali文件中，判斷是否相等的部分。改爲常量true,即失效。
總之，反編譯一些apk之後，只要是java代碼寫的總會有smil文件。對於smil文件，如果耐心讀的話，還是可以查看到一些關鍵代碼的。
第三方加密工具
相較於應用來說，遊戲apk因爲採用cocos2d-x 或者 unity3D，採用的是c++ 和c# 編寫的跨平臺程序，在apk採用JNI的方式。所以沒有smali，可以防止靜態被破解apk包。
當然遊戲包apk 在運行的時候，會把.*so加載到內存中。動態也是可以在內存中抓取相應的數據。只不NDK 相對於smali破解來說，根部不是一個層級的關係。
難道真的就沒有好的加密方式嗎。想做一個應用非要把核心部分使用ndk這麼複雜的東西嘛。
其實，我們完全可以藉助第三方工具。下文就以愛加密gameChange.apk爲例展開篇幅。
該classes.dex是我原來的代碼。沒有混淆，沒有任何的加密保護。反編譯的話，真的是一絲不掛的漏了出來。
該classes.dex是經過愛加密處理之後的，反編譯之後發現莫名其妙的代碼。其實這兩個類是，運行使用jni加載so庫的代碼。
NativeApplication 類，加載exec.so和execmain.so ，裏面應該是固定的代碼，是對源碼
SuperApplication繼承自Application，程序主入口：
在加密之後的apk包中，多了一個assets目錄，該目錄下，有一些ijiami.dat，其實這個就是我們原來的classex.dex
基本原理是在jni層， 使用DexClassLoader動態加載技術完成對加密classex.dex的動態加載，內存中解密classex.dex，完成動態加載。
//PS：使用DexClassLoader動態加載技術
可以使用Android DexClassLoader完成DEX的動態加載，DEX文件可以附屬在assert或raw目錄也可以運行時從網絡下載。
我們知道DexClassLoader加載的類是沒有組件生命週期的，也就是說即使DexClassLoader通過對APK的動態加載完成了對組件類的加載，當系統啓動該組件時，還會出現加載類失敗的異常。爲什麼組件類被動態加載入虛擬機，但系統卻出現加載類失敗呢？
通過查看Android源代碼我們知道組件類的加載是由另一個ClassLoader來完成的，DexClassLoader和系統組件ClassLoader並不存在關係，系統組件ClassLoader當然找不到由DexClassLoader加載的類，如果把系統組件ClassLoader的parent修改成DexClassLoader，我們就可以實現對apk代碼的動態加載。
更多精彩請瀏覽上海安卓培訓官網。