安卓编译完打包命令

① 如何反编译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，不能直接替换（因为签名不一样）