確認你工程內bulid.gradle內相關屬性值及調用的jar和庫描述正確
點擊build-Rebuild Project(即刪除build下的所有文件並且重新build)
⑵ 對安卓應用加密防apk反編譯現在有不少討論,哪些有效呢
現在的Android
APK防止破解和反編譯的辦法,都是用混淆代碼和防二次打包的加密技術。不過這兩樣加密技術都已無用了!!!
對Android
APK的加密保護只有對DEX、RES、SO庫等主要文件進行了保護,才能有效的防止破解和反編譯。現在有很多的Android開發者都在使用愛加密APK源代碼安全保護,聽說效果不錯!!!
⑶ android系統編譯能用分布式編譯嗎
項目越來越大,每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下,找到以下可以幫助提高速度的方法,總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache,可以將ccache的緩存文件設置在tmpfs上,但是這樣的話,每次開機後,ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中,避免終端設備(慢速設備)拖慢速度。
tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾,也許這個數字是有點誇張了,不過粗想想,把文件放到內存上做編譯應該是比在磁碟上快多了吧,尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低,在Linux中,直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求,也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度:
用物理磁碟:40分16秒
用tmpfs:39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說,編譯過程中可能還會有打包等IO密集的操作,所以只要可能,用tmpfs是有益無害的。當然對於大項目來說,你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸,那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數,可以把項目在進行並行編譯,比如在一台雙核的機器上,完全可以用make -j4,讓make最多允許4個編譯命令同時執行,這樣可以更有效的利用CPU資源。
還是用Kernel來測試:
用make: 40分16秒
用make -j4:23分16秒
用make -j8:22分59秒
由此看來,在多核CPU上,適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多,一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的,如果項目的Makefile不規范,沒有正確的設置好依賴關系,並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守,則可能本身編譯的可並行度就下降了,也不能取得最佳的效果。
ccache
ccache工作原理:
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存,必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的,確保了與直接使用GCC獲得完全相同的輸出。
ccache用於把編譯的中間結果進行緩存,以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了,因為經常需要修改一些Kernel的代碼,然後再重新編譯,而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說,也是一樣。為什麼不是直接用make所支持的增量編譯呢?還是因為現實中,因為Makefile的不規范,很可能這種「聰明」的方案根本不能正常工作,只有每次make clean再make才行。
安裝完ccache後,可以在/usr/local/bin下建立gcc,g++,c++,cc的symbolic link,鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了(通常情況下/usr/local /bin會在PATH中排在/usr/bin前面)。
安裝的另外一種方法:
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++,而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時,使用g++編譯器時會自動啟動ccache
繼續測試:
用ccache的第一次編譯(make -j4):23分38秒
用ccache的第二次編譯(make -j4):8分48秒
用ccache的第三次編譯(修改若干配置,make -j4):23分48秒
看來修改配置(我改了CPU類型...)對ccache的影響是很大的,因為基本頭文件發生變化後,就導致所有緩存數據都無效了,必須重頭來做。但如果只是修改一些.c文件的代碼,ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴,布署成本很低,這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況:
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到,顯然只有第二編次譯時cache命中了,cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟,還是完全可以接受的。
distcc
一台機器的能力有限,可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的,因為可能每個開發人員都有自己的開發編譯環境,它們的編譯器版本一般是一致的,公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc,並不像想像中那樣要求每台電腦都具有完全一致的環境,它只要求源代碼可以用make -j並行編譯,並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上,預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成,所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後,可以啟動一下它的服務:
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數,設置可以參與編譯的機器列表。通常localhost也參與編譯,但如果可以參與編譯的機器很多,則可以把localhost從這個列表中去掉,這樣本機就完全只是進行預處理、分發和鏈接了,編譯都在別的機器上完成。因為機器很多時,localhost的處理負擔很重,所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++,gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候,也必須用-j參數,一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下:
一台雙核計算機,make -j4:23分16秒
兩台雙核計算機,make -j4:16分40秒
兩台雙核計算機,make -j8:15分49秒
跟最開始用一台雙核時的23分鍾相比,還是快了不少的。如果有更多的計算機加入,也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用,通過設置一個環境變數就可以做到,非常方便。
總結一下:
tmpfs: 解決IO瓶頸,充分利用本機內存資源
make -j: 充分利用本機計算資源
distcc: 利用多台計算機資源
ccache: 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低,綜合利用這些工具,就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法,更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件,這樣發生錯誤時,能夠查看。
⑷ Android 如何對apk文件進行反編譯以及重新
第一:使用apktool直接反編譯apk
第六:把生成的hellodemo.apk安裝到手機,可以看到主界面上已經顯示的是hello,而不再是你好。說明反編譯重新打包成功!
⑸ android系統怎麼二次開發
Android系統的二次開發,主要是在手機生產廠家,主要工作是對原生的Android系統進行底層修改,達到自己想要的產品。如:增加相機的功能、修改通訊錄顯示、SIM鎖定運營商(定製機)、修改開機啟動畫面等工作。首先你要下載Android源碼,編譯,刷機,調試自學是很難完成的,一般都是在公司的成長過程中學習。
⑹ 如何反編譯android應用並重新打包
apktool所需文件:
a、 apktool1.5.2.tar.bz2
b、apktool-install-windows-r05-ibot.tar.bz2 (windows系統)
2.解壓剛剛的文件,並將解壓的文件放入C:Windows目錄下
3.啟動控制台,輸入apktool,回車可查看到apktool工具常用指令
4.新建一個文件夾,用於存放apk及待解壓的文件,這里筆者將文件夾建在D:apk目錄,同時放入用於測試的android app包(test.apk)
5.控制台輸入:apktool d D:apk est.apk D:apk est 進行反編譯操作
中句話中「D:apk est.apk」指apk存放位置,「D:apk est」指反編譯後文件存放的位置
6.反編譯成功之後,進入D:apk est文件目錄可以查看到反編譯後的文件
⑺ 安卓反編譯出來的代碼如何修改重新生成APK
反編譯步驟:
下載apktool 並設置環境變數
命令行進入apk目錄執行:apktool d xx.apk (如果遇到一些錯誤說明apk做了防破解處理)
執行成功後會生成xx文件夾,進入xx文件夾修改需要修改的內容,如果需要修改代碼,進入xxsmali裡面,需要懂一些smali語法
修改完後回到命令行,執行:apktool b xx ,會在xx文件夾裡面生成一個dist文件夾,裡面的apk就是回編譯的,這個apk是沒有簽名的
下載網上的簽名工具對apk簽名,完了就可以安裝了(如果你下載了源碼或者sdk,裡面自帶一個signapk也可以簽名)
⑻ 如何反編譯android應用以及重編譯,簽名和對齊優化
首先,了解一下我們為什麼需要反編譯apk
大部分情況下,是由於想本地化一款優秀的應用,才需要做這事兒;又或者進行少量的smali修改以達到想要的效果(如添加歸屬地,使3G版Nexus 7支持Wi-Fi熱點)。
下面我們先准備運行環境和工具
建立工作目錄,如.\workspace\apktoolbox (下面同樣以此路徑為例)
必不可少的JDK:Oracle java下載,安裝完成後把<jdk-inst-path>\bin添加到$PATH環境變數中
反編譯和重編譯工具apktool:Google Code下載,按平台下載(一個apktool-install-<platform>-<ver>-tar.bz2,一個apktool<ver>.tar.bz2,下載完成後解壓至.\workspace\apktoolbox\bin
密鑰文件,共4組。test/shared/media/platform,從android source中獲取,分別對應不同共享用戶ID時簽名所需(查看應用AndroidManifest.xml第二行android:sharedUserId項 ),放到.\workspace\apktoolbox\bin下
test - 無android:sharedUserId項
shared - android:sharedUserId=android.uid.shared
media - android:sharedUserId=android.uid.media
platform - android:sharedUserId=android.uid.system
簽名工具signapk.jar,放到.\workspace\apktoolbox\bin下
對齊優化工具zipalign(從android sdk中獲取,在tools目錄下),放到.\workspace\apktoolbox\bin下
准備工作完成
接下來我們就要開始工作了(以本地化工作為例)
把待反編譯的apk放到.\workspace\apktoolbox\apks下
在命令行模式下進入.\workspace\apktoolbox\bin目錄,輸入以下命令進行解包(反編譯)
apktool d ..\apks\<apkfile>.apk ..\apks\<outdir>
.\workspace\apktoolbox\apks\<outdir>\res下的values目錄(英文原版)和values-r<locale>目錄(本地化)就是我們需要的對象。
本地化工作完成後,在命令行中輸入以下命令進行重新打包(重新編譯)
apktool b ..\apks\<outdir>
.\workspace\apktoolbox\apks\<outdir>\dist目錄下會生成重新打包後的apk(未簽名,未對齊優化)
重新打包完成後,在命令行中輸入以下命令進行簽名(根據實際情況選用密鑰,這里以test密鑰為例)
java -jar signapk.jar testkey.x509.pem testkey.pk8 ..\apks\<outdir>\dist\<apkfile>.apk ..\apks\<apkfile>_signed.apk
簽名完成後,在命令行中輸入以下命令進行對齊優化
zipalign -f -v 4 ..\apks\<apkfile>_signed.apk ..\apks\<apkfile>_zipaligned.apk
<apkfile>_zipaligned.apk就是我們最終需要的apk了。
完成
部分apk需要系統框架資源,沒有的話在重新打包時會報錯,這種情況下我們只需要先安裝一下對應系統框架即可(從你目標ROM中把/system/framework/framework-res.apk提取出,放到.\workspace\apktoolbox\apks下)。在命令行中輸入以下命令進行安裝
apktool if ..\apks\framework-res.apk
⑼ 如何做好APP加密,防止被反編譯,二次打包
App加密屬於App安全的重要步驟之一,主要通過本地數據文件保護,頁面防釣魚保護,鍵盤監聽保護,截屏保護和協議加密。源碼安全包括:動態指令載入,DEX加花加殼保護,SO文件保護和內存防mp,資源文件保護保護等等。單一的加密方式可能比較簡單,比較容易被破解,但是組合起來效果就會很好。不過專業加密首先還是得找一個專業權威的安卓APP加固平台,對APP進行加固保護。個人推薦深圳海雲安,他們最新推出的第六代無殼加固技術是行業內領先的安全加固技術,是目前安全度數最高的。
⑽ 如何給安卓應用編譯
把常用的應用程序編譯到img文件中,就成了系統的一部分,用戶不必自己安裝,當然也卸載不了;
同時也可以刪減系統自帶的應用程序,精簡系統;
1.\build\target\proct 目錄下generic.mk文件:
Java代碼 收藏代碼
PRODUCT_PACKAGES := \
AccountAndSyncSettings \
DeskClock \
AlarmProvider \
Bluetooth \
Calculator \
Calendar \
Camera \
testMid \
CertInstaller \
DrmProvider \
Email \
Gallery3D \
LatinIME \
Launcher2 \
Mms \
Music \
我們添加一個testMid \ 應用名稱。
2.把testMid包放入
\packages\apps 目錄下,修改android.mk文件。
Java代碼 收藏代碼
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := testMid
LOCAL_CERTIFICATE := platform
include $(BUILD_PACKAGE)
註:LOCAL_PACKAGE_NAME := testMid (包名必須和generic.mk中添加的相同)
編譯源碼,可以看到在
\out\target\proct\smdkv210\system\app
目錄下生存了testMid.apk了。這時system.img也包含了此應用。
-------------------------------------------------------------------
特殊情況:有時,應用需要包含jar包,這時的app導入源碼時會出現問題:
MODULE.TARGET.JAVA_LIBRARIES.libarity already defined by ... stop
由於 LOCAL_STATIC_JAVA_LIBRARIES := libarity 會引發錯誤信息。
目前解決方法是:
\build\core 目錄下修改base_rules.mk
注釋掉錯誤信息:
ifdef $(mole_id)
#$(error $(LOCAL_PATH): $(mole_id) already defined by $($(mole_id)))
endif
$(mole_id) := $(LOCAL_PATH)
--重新編譯,這時可以通過了。
(2)、刪除原廠(Telchips)帶源碼的應用程序,如DTV_DVBT
在/device/telechips/m801/device.mk
注釋掉相應語句:
# PRODUCT_PACKAGES += \
# SampleDVBTPlayer \
同時,在/out/target/proct/m801/system/app 找到相應的.APK包,並刪除