安卓編譯完打包命令

① 如何反編譯android應用並重新打包

一.看android的源代碼

1)將Apkd.apk 用zip解壓後，出現了一個classes.dex文件
2014/02/19 19:42
.
2014/02/19 19:42
..
2014/02/19 15:35 1,656 AndroidManifest.xml
2014/02/19 15:35 687,024 classes.dex
2014/02/19 15:49
META-INF
2014/02/19 15:49
res
2014/02/19 15:35 2,200 resources.arsc
2)進入到dex2jar目錄中，運行情況如下：
D:\developer\tools\test_apk\dex2jar-0.0.9.15>dex2jar.bat "..\Apkd(d2j)\classes.d
ex"
this cmd is deprecated, use the d2j-dex2jar if possible
dex2jar version: translator-0.0.9.15
dex2jar ..\Apkd(d2j)\classes.dex -> ..\Apkd(d2j)\classes_dex2jar.jar
Done.
在apk所在的目錄會出現 classes_dex2jar.jar 文件。
3) 用JD-GUI對jar包進行查看，可以查看源文件

二.反編譯apk

1.在下載APKTOOL中的三個文件（aapt.exe、apktool.bat、apktool.jar）解壓縮到你的Windows安裝目錄下，以方便使用Dos命令.
2012/12/06 11:44 854,016 aapt.exe
2014/02/19 17:15 277,372 Apkd.apk//示例用apk文件
2012/12/23 23:39 92 apktool.bat
2013/02/03 02:37 2,655,843 apktool.jar
2.進入到apktool.bat所在的目錄，運行：
apktool d Apkd.apk decode_dir
反編譯後,decode_dir目錄下的內容如下：
2014/02/19 17:16 716 AndroidManifest.xml
2014/02/19 17:16 237 apktool.yml
2014/02/19 17:18
build
2014/02/19 17:16
res
2014/02/19 17:16
smali
此時我可以查看原文件AndroidManifest.xml了，也是查看smali源文件（是用smali語言寫的，可以對照java看）。

三.APKTOOL的使用

1).decode
該命令用於進行反編譯apk文件，一般用法為
apktool d

代表了要反編譯的apk文件的路徑，最好寫絕對路徑，比如C:\MusicPlayer.apk
代表了反編譯後的文件的存儲位置，比如C:\MusicPlayer
如果你給定的已經存在，那麼輸入完該命令後會提示你，並且無法執行，需要你重新修改命令加入-f指令
apktool d –f

這樣就會強行覆蓋已經存在的文件
2).build
該命令用於編譯修改好的文件，一般用法為
apktool b

這里的
就是剛才你反編譯時輸入的
（如C:\MusicPlayer）,輸入這行命令後，如果一切正常，你會發現C:\MusicPlayer內多了2個文件夾build和dist，其中分別存儲著編譯過程中逐個編譯的文件以及最終打包的apk文件。
3).install-framework
該命令用於為APKTool安裝特定的framework-res.apk文件，以方便進行反編譯一些與ROM相互依賴的APK文件。具體情況請看常見問題

四.smali與java源碼對照，並做出相應的修改

java源代碼：

import android.os.Bundle;
import android.app.Activity;
import android.view.Menu;
import android.widget.*;

public class MainActivity extends Activity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TextView a = (TextView)this.findViewById(R.id.test) ;
a.setText("raoliang");
}

@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}

}

對應的smali源代碼：
.class public Lali/text/apkd/MainActivity;
.super Landroid/app/Activity;
.source "MainActivity.java"

# direct methods
.method public constructor ()V
.locals 0

② 如何用命令行編譯打包生成apk

一、搭建搭建環境
1. 安裝JDK 和 Android SDK
2. 配置環境變數
D:\android-sdk-windows\tools
C:\Program Files\Java\jdk1.6.0_20\bin
3. 例子信息
項目目錄：D:\ProjectDemo
SDK目錄 ：D:\android-sdk-windows\platforms\android-8\
二、命令行編譯Android項目
1. 生成R文件
2. Java代碼生成class文件
3. class文件生成dex文件
4. 打包資源
5. 生成apk
6. 創建密匙
7. 簽名apk

③ 用java或C#調用命令行對android工程進行編譯、打包和簽名，急求！！

Android本身是支持ant打包項目的，並且SDK中自帶一個build.xml文件。
通過該文件，可以對文件進行編譯、打包、安裝等。並且支持多種方式打包，如debug或者release。
一般的，可以按照如下方法進行操作：

首先創建一個Android工程。
工程創建好後，需要為工程添加ant支持，即創建相應的build.xml文件。
這個文件不需要用戶自己創建，只需要執行如下命令即可：
<sdk>/tools/android update project -p <project> -t <target>

其中：
sdk為sdk的安裝目錄，其下的tools/android是我們要使用的命令。
project為項目目錄。
target為項目所使用的android的target id，也就是項目對應的android的版本。

可以將sdk的tools目錄添加到環境變數 ~/.bashrc 文件中，重啟後生效，以後可以直接使用命令了。
可以通過執行以下命令查看當前sdk中所包含的target以及相應id：
android list targets

執行完android update project命令後，會在項目的根目錄下生成相應的ant文件。
主要有build.xml、ant.properties、local.properties三個文件。
如果沒有ant.properties文件，可以自己手動添加。

其中，build.xml文件是進行ant build的主要文件，它引用了其它的文件。
在local.properties文件中定義了sdk.dir屬性，也就是當前使用的sdk的目錄。
在ant.properties文件中，可以定義自己的一些屬性，或者重定義一些屬性。
當然，這兩個屬性文件可有可無，直接定義到build.xml中也沒有關系。

在build.xml中的最後，引用了sdk目錄下的tools/ant/build.xml文件。
這個是sdk默認的build文件，可以將其內容直接拷貝過來，也可以保持當前的引用方式。
項目下的build.xml默認執行的target是help，運行後可以看到相關的幫助信息。
通過幫助信息，可以看到其它可用的target。
一般的，我們需要修改為debug或者release。
修改好之後，再運行build.xml文件，就會執行我們需要的編譯過程了。
build.xml文件的執行方法為：右鍵->Run As->Ant Build。

如果是debug版的話，默認會使用debug方式簽名。
如果是release版的話，需要指定相應的keystore以及私鑰。
否則，最後只能生成一個沒有簽名的apk文件。

設定私鑰庫的方法是，在ant.properties文件中，添加如下內容：
key.store=<keystore>
key.alias=<key>
key.store.password=<keystore pwd>
key.alias.password=<key pwd>

其中：
keystore為私鑰庫文件。
key為簽名需要使用的私鑰。
key.store.password為私鑰庫的密碼。
key.alias.password為私鑰的密碼。

兩個密碼相關的屬性也可以不添加，而只添加私鑰庫及私鑰。
這樣的話，執行時會依次彈出相應的輸入框，提示用戶輸入相應的密碼。
這樣雖然相對繁瑣，但是由於沒有明文指定密碼，對私鑰庫的保護會更好一些。

如果項目引用了第三方庫的話，只需要在項目根目錄創建libs文件夾並將其放入即可。
如果是jar庫，直接放到libs目錄下；如果是so庫，需要放到libs的名為armeabi的子目錄下。
也可以通過設定相應的屬性來指定第三方庫的位置，其默認都是libs文件夾。
jar.libs.dir為jar類型庫所在的目錄。
native.libs.absolute.dir為so類型庫所在的目錄，即armeabi的父目錄。

如果項目包含了jni代碼，希望在打包時自動重新編譯so庫，可以修改build.xml文件。
修改方法為，在引用sdk的build.xml文件之前添加如下target：
<target name="-pre-build" depends="-ndk-build">
</target>
<target name="-ndk-build">
<exec executable="ndk-build" failonerror="true">
<arg value="clean" />
</exec>
<exec executable="ndk-build" failonerror="true" />
</target>

ndk-build為ndk提供的命令，需要將ndk安裝目錄添加到環境變數中，添加方法同sdk/tools。
生成的so默認會放到libs/armeabi目錄下。

使用默認的build.xml打包apk時，已經包含了混淆、簽名、對齊優化等相關過程。
如果是使用release的方式，最後生成的apk文件已經可以直接發布了。

④ 如何打包安卓手機Zip升級包如何簽名不換Recovery，用官方Recovery

通過分析update.zip包在具體Android系統升級的過程，來理解Android系統中Recovery模式服務的工作原理。
我們先從update.zip包的製作開始，然後是Android系統的啟動模式分析，Recovery工作原理，如何從我們上層開始選擇system update到重啟到Recovery服務，以及在Recovery服務中具體怎樣處理update.zip包升級的，我們的安裝腳本updater-script怎樣被解析並執行的等一系列問題。分析過程中所用的Android源碼是gingerbread0919（tcc88xx開發板標配的），測試開發板是tcc88xx。
一、 update.zip包的目錄結構
|----boot.img
|----system/
|----recovery/
`|----recovery-from-boot.p
`|----etc/
`|----install-recovery.sh
|---META-INF/
`|CERT.RSA
`|CERT.SF
`|MANIFEST.MF
`|----com/
`|----google/
`|----android/
`|----update-binary
`|----updater-script
`|----android/
`|----metadata
二、 update.zip包目錄結構詳解
以上是我們用命令make otapackage 製作的update.zip包的標准目錄結構。
1、boot.img是更新boot分區所需要的文件。這個boot.img主要包括kernel+ramdisk。
2、system/目錄的內容在升級後會放在系統的system分區。主要用來更新系統的一些應用或則應用會用到的一些庫等等。可以將Android源碼編譯out/target/proct/tcc8800/system/中的所有文件拷貝到這個目錄來代替。
3、recovery/目錄中的recovery-from-boot.p是boot.img和recovery.img的補丁(patch),主要用來更新recovery分區，其中etc/目錄下的install-recovery.sh是更新腳本。
4、update-binary是一個二進制文件，相當於一個腳本解釋器，能夠識別updater-script中描述的操作。該文件在Android源碼編譯後out/target/proct/tcc8800/system bin/updater生成，可將updater重命名為update-binary得到。
該文件在具體的更新包中的名字由源碼中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
5、updater-script：此文件是一個腳本文件，具體描述了更新過程。我們可以根據具體情況編寫該腳本來適應我們的具體需求。該文件的命名由源碼中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
6、 metadata文件是描述設備信息及環境變數的元數據。主要包括一些編譯選項，簽名公鑰，時間戳以及設備型號等。
7、我們還可以在包中添加userdata目錄，來更新系統中的用戶數據部分。這部分內容在更新後會存放在系統的/data目錄下。
8、update.zip包的簽名：update.zip更新包在製作完成後需要對其簽名，否則在升級時會出現認證失敗的錯誤提示。而且簽名要使用和目標板一致的加密公鑰。加密公鑰及加密需要的三個文件在Android源碼編譯後生成的具體路徑為：
out/host/linux-x86/framework/signapk.jar
build/target/proct/security/testkey.x509.pem
build/target/proct/security/testkey.pk8 。
我們用命令make otapackage製作生成的update.zip包是已簽過名的，如果自己做update.zip包時必須手動對其簽名。
具體的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/proct/security/testkey.x509.pem gingerbread/build/target/proct/security/testkey.pk8 update.zip update_signed.zip
以上命令在update.zip包所在的路徑下執行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用絕對路徑。update.zip 是我們已經打好的包，update_signed.zip包是命令執行完生成的已經簽過名的包。
9、MANIFEST.MF：這個manifest文件定義了與包的組成結構相關的數據。類似Android應用的mainfest.xml文件。
10、CERT.RSA：與簽名文件相關聯的簽名程序塊文件，它存儲了用於簽名JAR文件的公共簽名。
11、CERT.SF：這是JAR文件的簽名文件，其中前綴CERT代表簽名者。
另外，在具體升級時，對update.zip包檢查時大致會分三步：①檢驗SF文件與RSA文件是否匹配。②檢驗MANIFEST.MF與簽名文件中的digest是否一致。③檢驗包中的文件與MANIFEST中所描述的是否一致。
三、 Android升級包update.zip的生成過程分析
1) 對於update.zip包的製作有兩種方式，即手動製作和命令生成。
第一種手動製作：即按照update.zip的目錄結構手動創建我們需要的目錄。然後將對應的文件拷貝到相應的目錄下，比如我們向系統中新加一個應用程序。可以將新增的應用拷貝到我們新建的update/system/app/下（system目錄是事先拷貝編譯源碼後生成的system目錄），打包並簽名後，拷貝到SD卡就可以使用了。這種方式在實際的tcc8800開發板中未測試成功。簽名部分未通過，可能與具體的開發板相關。
第二種製作方式：命令製作。Android源碼系統中為我們提供了製作update.zip刷機包的命令，即make otapackage。該命令在編譯源碼完成後並在源碼根目錄下執行。 具體操作方式：在源碼根目錄下執行
①$ . build/envsetup.sh。
②$ lunch 然後選擇你需要的配置(如17)。
③$ make otapackage。
在編譯完源碼後最好再執行一遍上面的①、②步防止執行③時出現未找到對應規則的錯誤提示。命令執行完成後生成的升級包所在位置在out/target/proct/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip將這個包重新命名為update.zip，並拷貝到SD卡中即可使用。
這種方式(即完全升級)在tcc8800開發板中已測試成功。
2) 使用make otapackage命令生成update.zip的過程分析。
在源碼根目錄下執行make otapackage命令生成update.zip包主要分為兩步，第一步是根據Makefile執行編譯生成一個update原包（zip格式）。第二步是運行一個python腳本，並以上一步准備的zip包作為輸入，最終生成我們需要的升級包。下面進一步分析這兩個過程。
第一步：編譯Makefile。對應的Makefile文件所在位置：build/core/Makefile。從該文件的884行（tcc8800,gingerbread0919）開始會生成一個zip包，這個包最後會用來製作OTA package 或者filesystem image。先將這部分的對應的Makefile貼出來如下：

[python] view plainprint?
# -----------------------------------------------------------------
# A zip of the directories that map to the target filesystem.
# This zip can be used to create an OTA package or filesystem image
# as a post-build step.
#
根據上面的Makefile可以分析這個包的生成過程：
首先創建一個root_zip根目錄，並依次在此目錄下創建所需要的如下其他目錄
①創建RECOVERY目錄，並填充該目錄的內容，包括kernel的鏡像和recovery根文件系統的鏡像。此目錄最終用於生成recovery.img。
②創建並填充BOOT目錄。包含kernel和cmdline以及pagesize大小等，該目錄最終用來生成boot.img。
③向SYSTEM目錄填充system image。
④向DATA填充data image。
⑤用於生成OTA package包所需要的額外的內容。主要包括一些bin命令。
⑥創建META目錄並向該目錄下添加一些文本文件，如apkcerts.txt(描述apk文件用到的認證證書)，misc_info.txt(描述Flash內存的塊大小以及boot、recovery、system、userdata等分區的大小信息)。
⑦使用保留連接選項壓縮我們在上面獲得的root_zip目錄。
⑧使用fs_config(build/tools/fs_config)配置上面的zip包內所有的系統文件(system/下各目錄、文件)的許可權屬主等信息。fs_config包含了一個頭文件#include「private/android_filesystem_config.h」。在這個頭文件中以硬編碼的方式設定了system目錄下各文件的許可權、屬主。執行完配置後會將配置後的信息以文本方式輸出 到META/filesystem_config.txt中。並再一次zip壓縮成我們最終需要的原始包。
第二步：上面的zip包只是一個編譯過程中生成的原始包。這個原始zip包在實際的編譯過程中有兩個作用，一是用來生成OTA update升級包，二是用來生成系統鏡像。在編譯過程中若生成OTA update升級包時會調用（具體位置在Makefile的1037行到1058行）一個名為ota_from_target_files的python腳本，位置在/build/tools/releasetools/ota_from_target_files。這個腳本的作用是以第一步生成的zip原始包作為輸入，最終生成可用的OTA升級zip包。
二 下面我們分析ota_from_target_files這個python腳本是怎樣生成最終zip包的。先講這個腳本的代碼貼出來如下：
[python] view plainprint?
import sys
if sys.hexversion < 0x02040000:
print >> sys.stderr, "Python 2.4 or newer is required."
sys.exit(1)
主函數main是python的入口函數，我們從main函數開始看，大概看一下main函數（腳本最後）里的流程就能知道腳本的執行過程了。
① 在main函數的開頭，首先將用戶設定的option選項存入OPTIONS變數中，它是一個python中的類。緊接著判斷有沒有額外的腳本，如果有就讀入到OPTIONS變數中。
② 解壓縮輸入的zip包，即我們在上文生成的原始zip包。然後判斷是否用到device-specific extensions（設備擴展）如果用到，隨即讀入到OPTIONS變數中。
③ 判斷是否簽名，然後判斷是否有新內容的增量源，有的話就解壓該增量源包放入一個臨時變數中（source_zip）。自此，所有的准備工作已完畢，隨即會調用該 腳本中最主要的函數WriteFullOTAPackage(input_zip,output_zip)
④ WriteFullOTAPackage函數的處理過程是先獲得腳本的生成器。默認格式是edify。然後獲得metadata元數據，此數據來至於Android的一些環境變數。然後獲得設備配置參數比如api函數的版本。然後判斷是否忽略時間戳。
⑤ WriteFullOTAPackage函數做完准備工作後就開始生成升級用的腳本文件(updater-script)了。生成腳本文件後將上一步獲得的metadata元數據寫入到輸出包out_zip。
⑥至此一個完整的update.zip升級包就生成了。生成位置在：out/target/proct/tcc8800/full_tcc8800_evm-ota-eng.mumu.20120315.155326.zip。將升級包拷貝到SD卡中就可以用來升級了。
四、 Android OTA增量包update.zip的生成
在上面的過程中生成的update.zip升級包是全部系統的升級包。大小有80M多。這對手機用戶來說，用來升級的流量是很大的。而且在實際升級中，我們只希望能夠升級我們改變的那部分內容。這就需要使用增量包來升級。生成增量包的過程也需要上文中提到的ota_from_target_files.py的參與。
下面是製作update.zip增量包的過程。
① 在源碼根目錄下依次執行下列命令
$ . build/envsetup.sh
$ lunch 選擇17
$ make
$ make otapackage
執行上面的命令後會在out/target/proct/tcc8800/下生成我們第一個系統升級包。我們先將其命名為A.zip
② 在源碼中修改我們需要改變的部分，比如修改內核配置，增加新的驅動等等。修改後再一次執行上面的命令。就會生成第二個我們修改後生成的update.zip升級包。將 其命名為B.zip。
③ 在上文中我們看了ota_from_target_files.py腳本的使用幫助，其中選項-i就是用來生成差分增量包的。使用方法是以上面的A.zip 和B.zip包作為輸入，以update.zip包作 為輸出。生成的update.zip就是我們最後需要的增量包。
具體使用方式是：將上述兩個包拷貝到源碼根目錄下，然後執行下面的命令。
$ ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip。
在執行上述命令時會出現未找到recovery_api_version的錯誤。原因是在執行上面的腳本時如果使用選項i則會調用WriteIncrementalOTAPackage會從A包和B包中的META目錄下搜索misc_info.txt來讀取recovery_api_version的值。但是在執行make otapackage命令時生成的update.zip包中沒有這個目錄更沒有這個文檔。
此時我們就需要使用執行make otapackage生成的原始的zip包。這個包的位置在out/target/proct/tcc8800/obj/PACKAGING/target_files_intermediates/目錄下，它是在用命令make otapackage之後的中間生產物，是最原始的升級包。我們將兩次編譯的生成的包分別重命名為A.zip和B.zip，並拷貝到SD卡根目錄下重復執行上面的命令：
$ ./build/tools/releasetools/ota_form_target_files -i A.zip B.zip update.zip。
在上述命令即將執行完畢時，在device/telechips/common/releasetools.py會調用IncrementalOTA_InstallEnd,在這個函數中讀取包中的RADIO/bootloader.img。
而包中是沒有這個目錄和bootloader.img的。所以執行失敗，未能生成對應的update.zip。可能與我們未修改bootloader（升級firmware）有關。此問題在下一篇博客已經解決。
製作增量包失敗的原因，以及解決方案。

Android系統Recovery工作原理之使用update.zip升級過程分析（二）---update.zip差分包問題的解決
在上一篇末尾提到的生成差分包時出現的問題，現已解決，由於最近比較忙，相隔的時間也比較長，所以單列一個篇幅提示大家。這個問題居然是源碼中的問題，可能你已經製作成功了，不過我的這個問題確實是源碼中的一個問題，不知道是不是一個bug，下文會具體分析！
一、生成OTA增量包失敗的解決方案
在上一篇中末尾使用ota_from_target_files腳本製作update.zip增量包時失敗，我們先將出現的錯誤貼出來。
在執行這個腳本的最後讀取input_zip中RADIO/bootloader.img時出現錯誤，顯示DeviceSpecifiParams這個對象中沒有input_zip屬性。
我們先從腳本中出現錯誤的調用函數中開始查找。出現錯誤的調用地方是在函WriteIncrementalOTAPackage（443行）中的device_specific.IncrementalOTA_InstallEnd()，其位於WriteIncrementalOTAPackage()中的末尾。進一步跟蹤源碼發現，這是一個回調函數，他的具體執行方法位於源碼中/device/telechips/common/releasetools.py腳本中的IncrementalOTA_InstallEnd()函數。下面就分析這個函數的作用。
releasetools.py腳本中的兩個函數FullOTA_InstallEnd()和IncrementalOTA_InstallEnd()的作用都是從輸入包中讀取RADIO/下的bootloader.img文件寫到輸出包中，同時生成安裝bootloader.img時執行腳本的那部分命令。只不過一個是直接將輸入包中的bootloader.img鏡像寫到輸出包中，一個是先比較target_zip和source_zip中的bootloader.img是否不同（使用選項-i生成差分包時），然後將新的鏡像寫入輸出包中。下面先將這個函數(位於/device/telechips/common/releasetools.py)的具體實現貼出來：
我們的實際情況是，在用命令make otapackage時生成的包中是沒有這個RADIO目錄下的bootloader.img鏡像文件（因為這部分更新已被屏蔽掉了）。但是這個函數中對於從包中未讀取到bootloader.img文件的情況是有錯誤處理的，即返回。所以我們要從 出現的實際錯誤中尋找問題的原由。
真正出現錯誤的地方是：
target_bootloader=info.input_zip.read(「RADIO/bootloader.img」)。
出現錯誤的原因是：AttributeError：『DeviceSpecificParams』object has no attribute 『input_zip』，提示我們DeviceSpecificParams對象沒有input_zip這個屬性。
二、updater-script腳本執行流程分析：
先看一下在測試過程中用命令make otapackage生成的升級腳本如下：
[python] view plainprint?
assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
assert(getprop("ro.proct.device") == "tcc8800" ||
下面分析下這個腳本的執行過程：
①比較時間戳：如果升級包較舊則終止腳本的執行。
②匹配設備信息：如果和當前的設備信息不一致，則停止腳本的執行。
③顯示進度條：如果以上兩步匹配則開始顯示升級進度條。
④格式化system分區並掛載。
⑤提取包中的recovery以及system目錄下的內容到系統的/system下。
⑥為/system/bin/下的命令文件建立符號連接。
⑦設置/system/下目錄以及文件的屬性。
⑧將包中的boot.img提取到/tmp/boot.img。
⑨將/tmp/boot.img鏡像文件寫入到boot分區。
⑩完成後卸載/system。
三、總結
以上的九篇著重分析了Android系統中Recovery模式中的一種，即我們做好的update.zip包在系統更新時所走過的流程。其核心部分就是Recovery服務的工作原理。其他兩種FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE與OTA INSTALL是相通的。重點是要理解Recovery服務的工作原理。另外詳細分析其升級過程，對於我們在實際升級時，可以根據我們的需要做出相應的修改。

⑤ android 工程 如何一鍵編譯打包成apk

打包步驟：

1、生成keystore

按照下面的命令行在C:ProgramFilesJavajdk1.6.0_10in>目錄下，輸入keytool-genkey-aliasandroid.keystore-keyalgRSA-validity100000-keystoreandroid.keystore

參數意義：-validity主要是證書的有效期，寫100000天；空格，退格鍵都算密碼。

命令執行後會在C:ProgramFilesJavajdk1.6.0_10in>目錄下生成android.keystore文件。如圖-1

圖-2EclipseAndroid打包工具

接下來的步驟就是不斷的next。下面僅貼出圖片，不解釋。

step2：選擇打包的項目

step3:選擇生成的EclipseAndroid.keystore文件並輸入密碼

step4：選擇aliaskey並輸入密碼

step5:最後選擇生成androidapk文件的目錄及文件名

最終生成的apk文件。

⑥ 如何反編譯android應用並重新打包

反編譯android步驟入下：

第一：使用apktool直接反編譯apk

第六：把生成的hellodemo.apk安裝到手機，可以看到主界面上已經顯示的是hello，而不再是你好。說明反編譯重新打包成功！

⑦ 編譯好的APK怎麼打包進Android鏡像

有一些apk 文件比較重要的，想直接打包到系統中，開機就能使用。網上網路了一下，只有說如何把apk文件打包到system.img 裡面，應該也是類似的。試試參考是否行。
把第三方或自己開發的apk文件編譯到系統文件(system.img)中的方法：
1 (1)源碼編譯後，把apk拷貝到out\target\proct\generic\system\app中。
(2) 執行命令make snod , 把添加的spk編到system.img 中
缺點：執行make clean 後，再次make 完畢需要重新執行上面操作。
2 "方法一"的改進。
(1) 新建一個文件夾目錄，用來存放apk文件
mkdir packages/apps/Prebuilt_apps
cd packages/apps/Prebuilt_apps
在Prebuilt_apps中新建make文件
vi Android.mk
並寫入
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_POST_PROCESS_COMMAND := $(shell cp -r $(LOCAL_PATH)/*.apk $(TARGET_OUT)/app/)
保存退出。
(2) 把需要編譯的apk拷貝到目錄Prebuilt_apps下，執行make ，Prebuilt_apps中的apk就會考被到out\target\proct\generic\system\app中。
(3) 執行make snod 。完成。
此方法執行make clean 後，再次make 完畢，只需要make snod即可(有時make後，out\target\proct\generic\system\app沒有需要添加的apk，此時再make一次即可，速度很快)。
-----------------------
感謝11樓提供的關於編譯成功但無法運行問題的解決方法。
解壓apk，如其中lib(.so)文件，把 .so文件到system\lib下，再編譯。
本人在模擬器上直接加入angrybird.apk（憤怒的小鳥）編譯，編譯後無法運行。把libangrybirds.so拷貝到system\lib下，再編譯後就可以運行

⑧ 如何應用安卓APK文件進行解包打包和修改

不需要解包跟打包，直接修改就可以，修改的的方法。

如下參考：

1.將需要修改的apk包復制到100apktool的路徑中。注意:您需要將文件名更改為123apk，如下圖。

⑨ 如何解包/編輯/打包android系統的boot.img文件

Android產品中，內核格式是Linux標準的zImage，根文件系統採用ramdisk格式。這兩者在Android下是直接合並在一起取名為boot.img,會放在一個獨立分區當中。這個分區格式是Android自行制定的格式。Android開發時，最標準的做法是重新編譯於內核和根文件系統，然後調用Android給的命令行文件mkbootimg(out/host/linux-x86/bin/)來打包。 在製作手機ROM時，有時會單獨編譯內核或抽出根文件進行修改內容，比如我只編譯內核，其餘的地方不變。這樣重新安裝巨大的Android開發環境實在不劃算。因此很多boot.img解包工具被人開發出來，這一些工具都是把內核和根文件系統從一個現成的boot.img抽取出來，修發後再次打包還原。一.常見的解包工具因為boot.img的格式比較簡單，它主要分為三大塊（有的可能有四塊）因此很多人開發分析工具，有是linuxshell腳本，比如repack-zImage，也有人採用perl,還有C語言編寫的unbootimg， 我使用的是在源碼位置system/core/mkbootimg/下的mkbootimg。為了簡化，藍點工坊把與mkbootimg中打包工具和解包工具以及所包含的libmincrpty庫抽出來，並且重寫一個Makefile,作為開源項目。使用者只需要在linux（需安裝gcc,make,一般是標配）或windows（需要安裝mingw）的命令行執行make,即可產生可執行文件mkbootimg，unpackbootimg。二.解/打包工具使用解包工具：unpackbootimg常見格式 unpackbootimg-i.\tmp\boot.img-o.\out 這一句命令行表示把boot.img解包，所有文件輸出到out目錄下它會解壓出如下文件：boot.img-zImage(內核文件）boot.img-ramdisk.gz(根文件系統打包文件） boot.img-cmdline(mkbootimgcmdline參數) boot.img-pagesize(mkbootimgpagesize參數) boot.img-base(mkbootimgbase參數)打包工具：mkbootimg（Android自帶）常見的命令格式： ./mkbootimg --cmdline'no_console_suspend=1console=null' --kernel zImage --ramdisk boot/boot.img-ramdisk.gz -o boot.img--base02e00000 這句含義是把內核文件zImage和boot目錄下的根文件壓縮包boot.img-ramdisk.gz打包成boot.img. 其中cmdline和base的值均來源於unpackbootimg的結果

⑩ 如何反編譯android應用並重新打包

一.看android的源代碼

1)將Apkd.apk 用zip解壓後，出現了一個classes.dex文件
2014/02/19 19:42
.
2014/02/19 19:42
..
2014/02/19 15:35 1,656 AndroidManifest.xml
2014/02/19 15:35 687,024 classes.dex
2014/02/19 15:49
META-INF
2014/02/19 15:49
res
2014/02/19 15:35 2,200 resources.arsc
2)進入到dex2jar目錄中，運行情況如下：
D:\developer\tools\test_apk\dex2jar-0.0.9.15>dex2jar.bat "..\Apkd(d2j)\classes.d
ex"
this cmd is deprecated, use the d2j-dex2jar if possible
dex2jar version: translator-0.0.9.15
dex2jar ..\Apkd(d2j)\classes.dex -> ..\Apkd(d2j)\classes_dex2jar.jar
Done.
在apk所在的目錄會出現 classes_dex2jar.jar 文件。
3) 用JD-GUI對jar包進行查看，可以查看源文件

二.反編譯apk

1.在下載APKTOOL中的三個文件（aapt.exe、apktool.bat、apktool.jar）解壓縮到你的Windows安裝目錄下，以方便使用Dos命令.
2012/12/06 11:44 854,016 aapt.exe
2014/02/19 17:15 277,372 Apkd.apk//示例用apk文件
2012/12/23 23:39 92 apktool.bat
2013/02/03 02:37 2,655,843 apktool.jar
2.進入到apktool.bat所在的目錄，運行：
apktool d Apkd.apk decode_dir
反編譯後,decode_dir目錄下的內容如下：
2014/02/19 17:16 716 AndroidManifest.xml
2014/02/19 17:16 237 apktool.yml
2014/02/19 17:18
build
2014/02/19 17:16
res
2014/02/19 17:16
smali
此時我可以查看原文件AndroidManifest.xml了，也是查看smali源文件（是用smali語言寫的，可以對照java看）。

三.APKTOOL的使用

1).decode
該命令用於進行反編譯apk文件，一般用法為
apktool d

代表了要反編譯的apk文件的路徑，最好寫絕對路徑，比如C:\MusicPlayer.apk
代表了反編譯後的文件的存儲位置，比如C:\MusicPlayer
如果你給定的已經存在，那麼輸入完該命令後會提示你，並且無法執行，需要你重新修改命令加入-f指令
apktool d –f

這樣就會強行覆蓋已經存在的文件
2).build
該命令用於編譯修改好的文件，一般用法為
apktool b

這里的
就是剛才你反編譯時輸入的
（如C:\MusicPlayer）,輸入這行命令後，如果一切正常，你會發現C:\MusicPlayer內多了2個文件夾build和dist，其中分別存儲著編譯過程中逐個編譯的文件以及最終打包的apk文件。
3).install-framework
該命令用於為APKTool安裝特定的framework-res.apk文件，以方便進行反編譯一些與ROM相互依賴的APK文件。具體情況請看常見問題

四.smali與java源碼對照，並做出相應的修改

java源代碼：

import android.os.Bundle;
import android.app.Activity;
import android.view.Menu;
import android.widget.*;

public class MainActivity extends Activity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TextView a = (TextView)this.findViewById(R.id.test) ;
a.setText("raoliang");
}

@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}

}

對應的smali源代碼：
.class public Lali/text/apkd/MainActivity;
.super Landroid/app/Activity;
.source "MainActivity.java"

# direct methods
.method public constructor ()V
.locals 0

.prologue
.line 8
invoke-direct {p0}, Landroid/app/Activity;->()V

return-void
.end method

# virtual methods
.method protected onCreate(Landroid/os/Bundle;)V
.locals 2
.parameter "savedInstanceState"

.prologue
.line 12
invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V

.line 13
const/high16 v1, 0x7f03

invoke-virtual {p0, v1}, Lali/text/apkd/MainActivity;->setContentView(I)V

.line 14
const/high16 v1, 0x7f08

invoke-virtual {p0, v1}, Lali/text/apkd/MainActivity;->findViewById(I)Landroid/view/View;

move-result-object v0

check-cast v0, Landroid/widget/TextView;

.line 15
.local v0, a:Landroid/widget/TextView;
const-string v1, "raoliang"

invoke-virtual {v0, v1}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V

.line 16
return-void
.end method

.method public onCreateOptionsMenu(Landroid/view/Menu;)Z
.locals 2
.parameter "menu"

.prologue
.line 21
invoke-virtual {p0}, Lali/text/apkd/MainActivity;->getMenuInflater()Landroid/view/MenuInflater;

move-result-object v0

const/high16 v1, 0x7f07

invoke-virtual {v0, v1, p1}, Landroid/view/MenuInflater;->inflate(ILandroid/view/Menu;)V

.line 22
const/4 v0, 0x1

return v0
.end method

通過對比可以看到，常量是沒有必變的，可以根據的smali的語法，進行相應的修改

五.3、打包、簽名和安裝修改後的apk

修改完了，就可以打包回apk了。執行以下命令：
apktool b decode_dir
在mygame目錄下的dist在會看到打包好的apk。
當然，現在一般是無法安裝的，因為apk還沒有簽名。下面就來簽名。簽名需要keystore文件，我已經有專用的keystore了，如果還沒有，請參閱這里進行生成。
執行以下命令為重新編譯的my_game.apk簽名：
jarsigner -verbose -keystore demo.keystore Apkd.apk demo.keystore
最後，在安裝到手機前，需要把手機中的已有版本先卸載，因為如果簽名不同，是不能覆蓋安裝的，會提示「應用程序未安裝」錯誤。
完整的運行情況如下：

D:\developer\tools\test_apk\new\decode\dist>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore
輸入keystore密碼：
再次輸入新密碼:
您的名字與姓氏是什麼？
[Unknown]： rao
您的組織單位名稱是什麼？
[Unknown]： rao
您的組織名稱是什麼？
[Unknown]：
您所在的城市或區域名稱是什麼？
[Unknown]：
您所在的州或省份名稱是什麼？
[Unknown]：
該單位的兩字母國家代碼是什麼
[Unknown]：
CN=rao, OU=rao, O=Unknown, L=Unknown, ST=Unknown, C=Unknown 正確嗎？
[否]： y

輸入的主密碼
（如果和 keystore 密碼相同，按回車）：

D:\developer\tools\test_apk\new\decode\dist>jarsigner -verbose -keystore demo.keystore Apkd.apk demo.keystore
輸入密鑰庫的口令短語：
正在添加： META-INF/MANIFEST.MF
正在添加： META-INF/DEMO_KEY.SF
正在添加： META-INF/DEMO_KEY.RSA
正在簽名： res/drawable-hdpi/ic_launcher.png
正在簽名： res/drawable-mdpi/ic_launcher.png
正在簽名： res/drawable-xhdpi/ic_launcher.png
正在簽名： res/drawable-xxhdpi/ic_launcher.png
正在簽名： res/layout/activity_main.xml
正在簽名： res/menu/main.xml
正在簽名： AndroidManifest.xml
正在簽名： classes.dex
正在簽名： resources.arsc

D:\developer\tools\test_apk\new\decode\dist>
到此為止，修改後的apk可以正常的安裝了，不過，在安裝之前，必須要先卸載以前的apk，不能直接替換（因為簽名不一樣）