压缩解压缩 笔记

知识点 压缩与打包

命令:gzip,gunzip,zcat,bzcat,xzcat,bzip2,bunzip2,xz,zip,unzip,tar.


压缩工具可以压缩文件的大小,这样在带宽恒定的情况下就可以更好的节约带宽资源了!

命令gzip

压缩命令,只能压缩文件,不能压缩目录!

[root@localhost test]# ll
-rw-r--r--. 1 root root 4083800 Oct 30 23:56 1.txt
[root@localhost test]# gzip 1.txt 
[root@localhost test]# ll
-rw-r--r--. 1 root root 1006316 Oct 30 23:56 1.txt.gz //压缩之后源文件没有了!大小也变小了
[root@localhost test]# zcat 1.txt.gz //可以查看该文件,但是如果文件很大不要使用,会一直刷屏!根本来不及看
[root@localhost test]# file 1.txt.gz 
1.txt.gz: gzip compressed data, was "1.txt", from Unix, last modified: Tue Oct 30 23:56:03 2018  //可以查看压缩包的详细信息!
[root@localhost test]# gzip -d 1.txt.gz //解压缩文件。由于压缩的时候把源文件也干掉了,所以现在解压出来就没有文件名重复的困扰了 
[root@localhost test]# ll
-rw-r--r--. 1 root root 4083800 Oct 30 23:56 1.txt
[root@localhost test]# gunzip 1.txt.gz 
[root@localhost test]# ll
-rw-r--r--. 1 root root 4083800 Oct 30 23:56 1.txt  //gunzip ==gzip -d 命令
[root@localhost test]# gzip -c 1.txt > /test/5.txt.gz
[root@localhost test]# ll
总用量 52
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root  3337 10月 31 11:48 1.txt
-rw-r--r--. 1 root root    63 10月 31 16:41 5.txt.gz




gzip命令后面可以跟压缩等级,从1-9强度依次变大!缺省值为-6级别。

bzip2命令 也是压缩文件命令,用法和gzip差不多,只是算法不一样!也是只能针对文件,无法针对目录.

[root@localhost ~]# yum install -y bizp2 //默认bzip2还没安装,下yunm安装!
[root@localhost test]# ll
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
[root@localhost test]# bzip2 www 
[root@localhost test]# ll
-rw-r--r--. 1 root root   228 10月 31 06:55 www.bz2
[root@localhost test]# bzcat www.bz2  //和zcat一样 查看内容
[root@localhost test]# bunzip2 www.bz2 
[root@localhost test]# ll
-rw-r--r--. 1 root root  8326 10月 31 06:55 www //正常的压缩和解压缩和gzip一样。
[root@localhost test]# bzip2 -c tt.txt > /tmp/gg.txt.bz2 //将tt.txt压缩并重定向到/tmp下 改名为gg.txt.bz2
[root@localhost test]# ll
-rw-r--r--. 1 root root    13 11月  1 10:06 tt.txt //源文件还在 
[root@localhost test]# ll /tmp
-rw-r--r--. 1 root root 52 11月  1 10:18 gg.txt.bz2 

xz命令 压缩文件命令,用法和选项和gzip差不多。默认情况下也是不安装的!先执行#yum install -y xz

[root@localhost test]# yum install -y xz
[root@localhost test]# ll
-rw-r--r--. 1 root root 20480 10月 31 07:25 fire2
[root@localhost test]# du -sh fire2 
20K	fire2    //源文件本来大小
[root@localhost test]# xz fire2
[root@localhost test]# du -sh fire2.xz 
4.0K	fire2.xz  //压缩之后的大小,比前面2个更狠!
[root@localhost test]# ll
drwxr-xr-x. 2 root root    6 10月 29 21:39 1
-rw-r--r--. 1 root root 1588 10月 31 07:25 fire2.xz
[root@localhost test]# file fire2.xz 
fire2.xz: XZ compressed data
[root@localhost test]# xz -d fire2.xz  //解压文件。
[root@localhost test]# xz -dc fire2.xz > /tmp/water.xz
[root@localhost test]# ll
-rw-r--r--. 1 root root 1588 10月 31 07:25 fire2.xz
[root@localhost test]# ll /tmp/
-rw-r--r--. 1 root root 20480 11月  1 10:29 water.xz //用法和上面的2个都差不多!
[root@localhost test]# xzcat hello.xz  //使用xzcat查看内容
- world! 1.txt

zip命令

前面3个只能压缩文件,但是zip命令却可以压缩目录。同样zip也是没有安装的。使用yum install - y zip

[root@localhost test]# yum install -y zip
[root@localhost test]# yum install -y unzip //连带解压也一起安装了!
[root@localhost test]# ll
drwxr-xr-x. 2 root root    6 10月 29 21:39 1
-rw-r--r--. 1 root root 1588 10月 31 07:25 fire2.xz
-rw-r--r--. 1 root root 1802 10月 31 07:22 fire3.tar.gz
-rw-r--r--. 1 root root   72 10月 29 21:40 hello.xz
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root   13 11月  1 10:06 tt.txt
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
-rw-r--r--. 1 root root 2321 10月 31 16:49 xxoo
[root@localhost test]# zip test.zip 1/ fire2.xz fire3 hello.xz semanage.conf tt.txt www 
	zip warning: name not matched: fire3
  adding: 1/ (stored 0%)
  adding: fire2.xz (stored 0%)
  adding: hello.xz (stored 0%)
  adding: semanage.conf (deflated 49%)
  adding: tt.txt (stored 0%)
  adding: www (deflated 98%)
[root@localhost test]# ll
drwxr-xr-x. 2 root root    6 10月 29 21:39 1
-rw-r--r--. 1 root root 1588 10月 31 07:25 fire2.xz
-rw-r--r--. 1 root root 1802 10月 31 07:22 fire3.tar.gz
-rw-r--r--. 1 root root   72 10月 29 21:40 hello.xz
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root 3901 11月  1 10:40 test.zip  //这个是压缩后的文件,可以看到源文件都还在!
-rw-r--r--. 1 root root   13 11月  1 10:06 tt.txt
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
-rw-r--r--. 1 root root 2321 10月 31 16:49 xxoo
[root@localhost test]# unzip test.zip 
Archive:  test.zip
replace fire2.xz? [y]es, [n]o, [A]ll, [N]one, [r]ename: n//由于源文件还在,所以解压的时候文件名会重复,所以会提示是否取代!

zip没有像zcat,bzcat,xzcat等查看命令。只有unzip -l xxoo.zip 命令来查看列表详细内容!

[root@localhost test]# unzip -l test.zip 
Archive:  test.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  10-29-2018 21:39   1/
     1588  10-31-2018 07:25   fire2.xz
       72  10-29-2018 21:40   hello.xz
     2321  10-31-2018 06:41   semanage.conf
       13  11-01-2018 10:06   tt.txt
     8326  10-31-2018 06:55   www
---------                     -------
    12320                     6 files

zip还可以加-r压缩目录

[root@localhost test]# ll
drwxr-xr-x. 2 root root   58 11月  1 10:46 123
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root   13 11月  1 10:06 tt.txt
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
-rw-r--r--. 1 root root 2321 10月 31 16:49 xxoo
[root@localhost test]# zip test.zip -r .
  adding: xxoo (deflated 49%)
  adding: semanage.conf (deflated 49%)
  adding: www (deflated 98%)
  adding: tt.txt (stored 0%)
  adding: 123/ (stored 0%)
  adding: 123/fire2.xz (stored 0%)
  adding: 123/fire3.tar.gz (deflated 1%)
  adding: 123/hello.xz (stored 0%)
[root@localhost test]# ll
drwxr-xr-x. 2 root root   58 11月  1 10:46 123
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root 7182 11月  1 10:48 test.zip
-rw-r--r--. 1 root root   13 11月  1 10:06 tt.txt
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
-rw-r--r--. 1 root root 2321 10月 31 16:49 xxoo
[root@localhost test]# file test.zip 
test.zip: Zip archive data, at least v2.0 to extract
[root@localhost test]# ll
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root 7182 11月  1 10:48 test.zip
-rw-r--r--. 1 root root   13 11月  1 10:06 tt.txt
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
-rw-r--r--. 1 root root 2321 10月 31 16:49 xxoo
[root@localhost test]# unzip test.zip -d /tmp/   //解压到指定目录下 -d
Archive:  test.zip
  inflating: /tmp/xxoo               
  inflating: /tmp/semanage.conf      
  inflating: /tmp/www                
 extracting: /tmp/tt.txt             
   creating: /tmp/123/
 extracting: /tmp/123/fire2.xz       
  inflating: /tmp/123/fire3.tar.gz   
 extracting: /tmp/123/hello.xz       
[root@localhost test]# ll /tmp
drwxr-xr-x. 2 root root    58 11月  1 10:46 123
-rw-r--r--. 1 root root    52 11月  1 10:18 gg.txt.bz2
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root    13 11月  1 10:06 tt.txt
-rw-r--r--. 1 root root 20480 11月  1 10:29 water.xz
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
-rw-r--r--. 1 root root  2321 10月 31 16:49 xxoo

tar命令

打包命令,命令格式:tar -cvf 打包后文件名 需要打包的文件

[root@localhost test]# ll
drwxr-xr-x. 2 root root    6 10月 29 21:39 1
-rw-r--r--. 1 root root    0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root   15 10月 29 21:40 hello
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
[root@localhost test]# tar -cvf www.tar 1 1.txt hello semanage.conf 
1/
1.txt
hello
semanage.conf
[root@localhost test]# ll
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
-rw-r--r--. 1 root root 10240 10月 31 06:56 www.tar
[root@localhost test]# tar -tf www.tar //查看打包的文件列表!
1/
1.txt
hello
semanage.conf

[root@localhost test]# tar -xvf www.tar
1/
1.txt
hello
semanage.conf
[root@localhost test]# ll
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
-rw-r--r--. 1 root root 10240 10月 31 06:56 www.tar
//使用命令tar -xvf www.tar 解包之后,源文件还在而且解压出来的文件会覆盖掉现有的文件,不会提示!所以有没有解包看不怎么出来!

[root@localhost test]# mkdir ./xixi
[root@localhost test]# ll
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
-rw-r--r--. 1 root root 10240 10月 31 06:56 www.tar
drwxr-xr-x. 2 root root     6 10月 31 07:03 xixi
[root@localhost test]# tar -xvf www.tar -C ./xixi
1/
1.txt
hello
semanage.conf
[root@localhost test]# ll
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
-rw-r--r--. 1 root root 10240 10月 31 06:56 www.tar
drwxr-xr-x. 3 root root    62 10月 31 07:05 xixi
[root@localhost test]# cd xixi
[root@localhost xixi]# ll
总用量 8
drwxr-xr-x. 2 root root    6 10月 29 21:39 1
-rw-r--r--. 1 root root    0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root   15 10月 29 21:40 hello
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf

//新建一个xixi目录,然后可以将www.tar解包到xixi里。可以看到源文件这些都在,只是在xixi里多了解包出来的东西!

有时候想批量打包东西,但是又有几个个别文件不想被打包,可以使用命令--exclude

[root@localhost test]# tar -cvf fire.tar .//将test里的文件批量打包!
./
./1/
./www
./1.txt
./hello
./semanage.conf
./xixi/
./xixi/1/
./xixi/1.txt
./xixi/hello
./xixi/semanage.conf
tar: ./fire.tar: 文件是归档文件;未输出
[root@localhost test]# ll
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root 30720 10月 31 07:13 fire.tar  //打包之后的fire.tar文件
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
drwxr-xr-x. 3 root root    62 10月 31 07:05 xixi
[root@localhost test]# tar -tf fire.tar 
./
./1/
./www
./1.txt
./hello
./semanage.conf
./xixi/
./xixi/1/
./xixi/1.txt
./xixi/hello
./xixi/semanage.conf
[root@localhost test]# mkdir /test1
[root@localhost test]# mv fire.tar /test1
[root@localhost test]# tar -cvf . --exclude hello --exclude xixi
tar: 谨慎地拒绝创建空归档文件
请用“tar --help”或“tar --usage”获得更多信息。
[root@localhost test]# tar -cvf fire2 . --exclude hello --exclude xixi  //hello 和 xixi不打包!其他都打包
./
./1/
./www
./1.txt
./semanage.conf
tar: ./fire2: 文件是归档文件;未输出
[root@localhost test]# tar -tf fire2
./
./1/
./www
./1.txt
./semanage.conf
[root@localhost test]# tar -tf /test1/fire.tar 
./
./1/
./www
./1.txt
./hello
./semanage.conf
./xixi/
./xixi/1/
./xixi/1.txt
./xixi/hello
./xixi/semanage.conf //通过tar -tf 可以看到2个打包里的文件列表是不一样的!

tar命令搭配压缩命令!通过上面的例子可以看到打包之后的文件非常大,所以我们还要对文件进行压缩。而我们基本上都是在打包的时候直接进行压缩手续。

[root@localhost test]# tar -zcvf fire3.tar.gz .
./
./1/
./www
./1.txt
./hello
./semanage.conf
./xixi/
./xixi/1/
./xixi/1.txt
./xixi/hello
./xixi/semanage.conf
[root@localhost test]# ll
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root 20480 10月 31 07:25 fire2
-rw-r--r--. 1 root root  1802 10月 31 07:22 fire3.tar.gz
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
drwxr-xr-x. 3 root root    62 10月 31 07:05 xixi

可以看到fire2 和fire3.tar.gz大小差别很大。fire3在打包的时候就进行了压缩。所以出来的结果逼fire2小很多! 然后可以是用命令 tar -zxvf fire3.tar.gz进行解压和解包

[root@localhost test]# mkdir hehe
[root@localhost test]# ll
总用量 44
drwxr-xr-x. 2 root root     6 10月 29 21:39 1
-rw-r--r--. 1 root root     0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root 20480 10月 31 07:25 fire2
-rw-r--r--. 1 root root  1802 10月 31 07:22 fire3.tar.gz
drwxr-xr-x. 2 root root     6 10月 31 07:31 hehe
-rw-r--r--. 1 root root    15 10月 29 21:40 hello
-rw-r--r--. 1 root root  2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root  8326 10月 31 06:55 www
drwxr-xr-x. 3 root root    62 10月 31 07:05 xixi
[root@localhost test]# tar -zxvf fire3.tar.gz ./hehe
tar: ./hehe:归档中找不到
[root@localhost test]# tar -zxvf fire3.tar.gz -C ./hehe  //解压包到指定目录需加选项-C 
./
./1/
./www
./1.txt
./hello
./semanage.conf
./xixi/
./xixi/1/
./xixi/1.txt
./xixi/hello
./xixi/semanage.conf
[root@localhost test]# ll hehe
总用量 20
drwxr-xr-x. 2 root root    6 10月 29 21:39 1
-rw-r--r--. 1 root root    0 10月 31 06:39 1.txt
-rw-r--r--. 1 root root   15 10月 29 21:40 hello
-rw-r--r--. 1 root root 2321 10月 31 06:41 semanage.conf
-rw-r--r--. 1 root root 8326 10月 31 06:55 www
drwxr-xr-x. 3 root root   62 10月 31 07:05 xixi


同样的也有tar配合bzip2的选项

tar

  • zcvf 对应的是gzip
  • zxvf 对应的是gunzip
  • jcvf 对应的是bzip2
  • jxvf 对应的是bunzip2
  • Jcvf 对应的是xz
  • Jxvf 对应的是xz -d

转载于:https://my.oschina.net/u/3997678/blog/2336970

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
https://github.com/iBotPeaches/Apktool Introduction Basic First lets take a lesson into apk files. apks are nothing more than a zip file containing resources and compiled java. If you were to simply unzip an apk like so, you would be left with files such as classes.dex and resources.arsc. $ unzip testapp.apk Archive: testapp.apk inflating: AndroidManifest.xml inflating: classes.dex extracting: res/drawable-hdpi/ic_launcher.png inflating: res/xml/literals.xml inflating: res/xml/references.xml extracting: resources.arsc However, at this point you have simply inflated compiled sources. If you tried to view AndroidManifest.xml. You'd be left viewing this. P4F0\fnversionCodeversionNameandroid*http://schemas.android.com/apk/res/androidpackageplatformBuildVersionCodeplatformBuildVersionNamemanifestbrut.apktool.testapp1.021APKTOOL Obviously, editing or viewing a compiled file is next to impossible. That is where Apktool comes into play. $ apktool d testapp.apk I: Using Apktool 2.0.0 on testapp.apk I: Loading resource table... I: Decoding AndroidManifest.xml with resources... I: Loading resource table from file: 1.apk I: Regular manifest package... I: Decoding file-resources... I: Decoding values */* XMLs... I: Baksmaling classes.dex... I: Copying assets and libs... $ Viewing AndroidManifest.xml again results in something much more human readable <?xml version="1.0" encoding="utf-8" standalone="no"?> <manifest xmlns:android="https://schemas.android.com/apk/res/android" package="brut.apktool.testapp" platformBuildVersionCode="21" platformBuildVersionName="APKTOOL"/> In addition to XMLs, resources such as 9 patch images, layouts, strings and much more are correctly decoded to source form. Decoding The decode option on Apktool can be invoked either from d or decode like shown below. $ apktool d foo.jar // decodes foo.jar to foo.jar.out folder $ apktool decode foo.jar // decodes foo.jar to foo.jar.out folder $ apktool d bar.apk // decodes bar.apk to bar folder $ apktool decode bar.apk // decodes bar.apk to bar folder $ apktool d bar.apk -o baz // decodes bar.apk to baz folder Building The build option can be invoked either from b or build like shown below $ apktool b foo.jar.out // builds foo.jar.out folder into foo.jar.out/dist/foo.jar file $ apktool build foo.jar.out // builds foo.jar.out folder into foo.jar.out/dist/foo.jar file $ apktool b bar // builds bar folder into bar/dist/bar.apk file $ apktool b . // builds current directory into ./dist $ apktool b bar -o new_bar.apk // builds bar folder into new_bar.apk $ apktool b bar.apk // WRONG: brut.androlib.AndrolibException: brut.directory.PathNotExist: apktool.yml // Must use folder, not apk/jar file InfoIn order to run a rebuilt application. You must resign the application. Android documentation can help with this. Frameworks Frameworks can be installed either from if or install-framework, in addition two parameters -p, --frame-path <dir> - Store framework files into <dir> -t, --tag <tag> - Tag frameworks using <tag> Allow for a finer control over how the files are named and how they are stored. $ apktool if framework-res.apk I: Framework installed to: 1.apk // pkgId of framework-res.apk determines number (which is 0x01) $ apktool if com.htc.resources.apk I: Framework installed to: 2.apk // pkgId of com.htc.resources is 0x02 $ apktool if com.htc.resources.apk -t htc I: Framework installed to: 2-htc.apk // pkgId-tag.apk $ apktool if framework-res.apk -p foo/bar I: Framework installed to: foo/bar/1.apk $ apktool if framework-res.apk -t baz -p foo/bar I: Framework installed to: foo/bar/1-baz.apk Migration Instructions v2.1.1 -> v2.2.0 Run the following commands to migrate your framework directory Apktool will work fine without running these commands, this will just cleanup abandoned files unix - mkdir -p ~/.local/share; mv ~/apktool ~/.local/share windows - move %USERPROFILE%\apktool %USERPROFILE%\AppData\Local v2.0.1 -> v2.0.2 Update apktool to v2.0.2 Remove framework file $HOME/apktool/framework/1.apk due to internal API update (Android Marshmallow) v1.5.x -> v2.0.0 Java 1.7 is required Update apktool to v2.0.0 aapt is now included inside the apktool binary. It's not required to maintain your own aapt install under $PATH. (However, features like -a / --aapt are still used and can override the internal aapt) The addition of aapt replaces the need for separate aapt download packages. Helper Scripts may be found here Remove framework $HOME/apktool/framework/1.apk Eagle eyed users will notice resources are now decoded before sources now. This is because we need to know the API version via the manifest for decoding the sources Parameter Changes Smali/baksmali 2.0 are included. This is a big change from 1.4.2. Please read the smali updates here for more information -o / --output is now used for the output of apk/directory -t / --tag is required for tagging framework files -advance / --advanced will launch advance parameters and information on the usage output -m / --match-original is a new feature for apk analysis. This retains the apk is nearly original format, but will make rebuild more than likely not work due to ignoring the changes that newer aapt requires After [d]ecode, there will be new folders (original / unknown) in the decoded apk folder original = META-INF folder / AndroidManifest.xml, which are needed to retain the signature of apks to prevent needing to resign. Used with -c / --copy-original on [b]uild unknown = Files / folders that are not part of the standard AOSP build procedure. These files will be injected back into the rebuilt APK. apktool.yml collects more information than last version SdkInfo - Used to repopulate the sdk information in AndroidManifest.xml since newer aapt requires version information to be passed via parameter packageInfo - Used to help support Android 4.2 renamed manifest feature. Automatically detects differences between resource and manifest and performs automatic --rename-manifest-package on [b]uild versionInfo - Used to repopulate the version information in AndroidManifest.xml since newer aapt requires version information to be passed via parameter compressionType - Used to determine the compression that resources.arsc had on the original apk in order to replicate during [b]uild unknownFiles - Used to record name/location of non-standard files in an apk in order to place correctly on rebuilt apk sharedLibrary - Used to help support Android 5 shared library feature by automatically detecting shared libraries and using --shared-lib on [b]uild Examples of new usage in 2.0 vs 1.5.x Old (Apktool 1.5.x) New (Apktool 2.0.x) apktool if framework-res.apk tag apktool if framework-res.apk -t tag apktool d framework-res.apk output apktool d framework.res.apk -o output apktool b output new.apk apktool b output -o new.apk v1.4.x -> v1.5.1 Update apktool to v1.5.1 Update aapt manually or use package r05-ibot via downloading Mac, Windows or Linux Remove framework file $HOME/apktool/framework/1.apk Intermediate Framework Files As you probably know, Android apps utilize code and resources that are found on the Android OS itself. These are known as framework resources and Apktool relies on these to properly decode and build apks. Every Apktool release contains internally the most up to date AOSP framework at the time of the release. This allows you to decode and build most apks without a problem. However, manufacturers add their own framework files in addition to the regular AOSP ones. To use apktool against these manufacturer apks you must first install the manufacturer framework files. Example Lets say you want to decode HtcContacts.apk from an HTC device. If you try you will get an error message. $ apktool d HtcContacts.apk I: Loading resource table... I: Decoding resources... I: Loading resource table from file: 1.apk W: Could not decode attr value, using undecoded value instead: ns=android, name=drawable W: Could not decode attr value, using undecoded value instead: ns=android, name=icon Can't find framework resources for package of id: 2. You must install proper framework files, see project website for more info. We must get HTC framework resources before decoding this apk. We pull com.htc.resources.apk from our device and install it $ apktool if com.htc.resources.apk I: Framework installed to: 2.apk Now we will try this decode again. $ apktool d HtcContacts.apk I: Loading resource table... I: Decoding resources... I: Loading resource table from file: /home/brutall/apktool/framework/1.apk I: Loading resource table from file: /home/brutall/apktool/framework/2.apk I: Copying assets and libs... As you can see. Apktool leveraged both 1.apk and 2.apk framework files in order to properly decode this application. Finding Frameworks For the most part any apk in /system/framework on a device will be a framework file. On some devices they might reside in /data/system-framework and even cleverly hidden in /system/app or /system/priv-app. They are usually named with the naming of "resources", "res" or "framework". Example HTC has a framework called com.htc.resources.apk, LG has one called lge-res.apk After you find a framework file you could pull it via adb pull /path/to/file or use a file manager application. After you have the file locally, pay attention to how Apktool installs it. The number that the framework is named during install corresponds to the pkgId of the application. These values should range from 1 to 9. Any APK that installs itself as 127 is 0x7F which is an internal pkgId. Internal Frameworks Apktool comes with an internal framework like mentioned above. This file is copied to $HOME/apktool/framework/1.apk during use. Warning Apktool has no knowledge of what version of framework resides there. It will assume its up to date, so delete the file during Apktool upgrades Managing framework files Frameworks are stored in $HOME/apktool/framework for Windows and Unix systems. Mac OS X has a slightly different folder location of $HOME/Library/apktool/framework. If these directories are not available it will default to java.io.tmpdir which is usually /tmp. This is a volatile directory so it would make sense to take advantage of the parameter --frame-path to select an alternative folder for framework files. Note Apktool has no control over the frameworks once installed, but you are free to manage these files on your own. Tagging framework files Frameworks are stored in the naming convention of: <id>-<tag>.apk. They are identified by pkgId and optionally custom tag. Usually tagging frameworks isn't necessary, but if you work on apps from many different devices and they have incompatible frameworks, you will need some way to easily switch between them. You could tag frameworks by: $ apktool if com.htc.resources.apk -t hero I: Framework installed to: /home/brutall/apktool/framework/2-hero.apk $ apktool if com.htc.resources.apk -t desire I: Framework installed to: /home/brutall/apktool/framework/2-desire.apk Then: $ apktool d HtcContacts.apk -t hero I: Loading resource table... I: Decoding resources... I: Loading resource table from file: /home/brutall/apktool/framework/1.apk I: Loading resource table from file: /home/brutall/apktool/framework/2-hero.apk I: Copying assets and libs... $ apktool d HtcContacts.apk -t desire I: Loading resource table... I: Decoding resources... I: Loading resource table from file: /home/brutall/apktool/framework/1.apk I: Loading resource table from file: /home/brutall/apktool/framework/2-desire.apk I: Copying assets and libs... You don't have to select a tag when building apk - apktool automatically uses the same tag, as when decoding. Smali Debugging Warning SmaliDebugging has been marked as deprecated in 2.0.3, and removed in 2.1. Please check SmaliIdea for a debugger. Apktool makes possible to debug smali code step by step, watch variables, set breakpoints, etc. General information Generally we need several things to run Java debugging session: debugger server (usually Java VM) debugger client (usually IDE like IntelliJ, Eclipse or Netbeans) client must have sources of debugged application server must have binaries compiled with debugging symbols referencing these sources sources must be java files with at least package and class definitions, to properly connect them with debugging symbols In our particular situation we have: server: Monitor (Previously DDMS), part of Android SDK, standard for debugging Android applications - explained here client: any JPDA client - most of decent IDEs have support for this protocol. sources: smali code modified by apktool to satisfy above requirements (".java" extension, class declaration, etc.). Apktool modifies them when decoding apk in debug mode. binaries: when building apk in debug mode, apktool removes original symbols and adds new, which are referencing smali code (line numbers, registers/variables, etc.) Info To successfully run debug sessions, the apk must be both decoded and built in debug mode. Decoding with debug decodes the application differently to allow the debug rebuild option to inject lines allowing the debugger to identify variables and types.-d / --debug General instructions Above information is enough to debug smali code using apktool, but if you aren't familiar with DDMS and Java debugging, then you probably still don't know how to do it. Below are simple instructions for doing it using IntelliJ or Netbeans. Decode apk in debug mode: $ apktool d -d -o out app.apk Build new apk in debug mode: $ apktool b -d out Sign, install and run new apk. Follow sub-instructions below depending on IDE. IntelliJ (Android Studio) instructions In IntelliJ add new Java Module Project selecting the "out" directory as project location and the "smali" subdirectory as content root dir. Run Monitor (Android SDK /tools folder), find your application on a list and click it. Note port information in last column - it should be something like "86xx / 8700". In IntelliJ: Debug -> Edit Configurations. Since this is a new project, you will have to create a Debugger. Create a Remote Debugger, with the settings on "Attach" and setting the Port to 8700 (Or whatever Monitor said). The rest of fields should be ok, click "Ok". Start the debugging session. You will see some info in a log and debugging buttons will show up in top panel. Set breakpoint. You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#". Trigger some action in application. If you run at breakpoint, then thread should stop and you will be able to debug step by step, watch variables, etc. Netbeans instructions In Netbeans add new Java Project with Existing Sources, select "out" directory as project root and "smali" subdirectory as sources dir. Run DDMS, find your application on a list and click it. Note port information in last column - it should be something like "86xx / 8700". In Netbeans: Debug -> Attach Debugger -> select JPDA and set Port to 8700 (or whatever you saw in previous step). Rest of fields should be ok, click "Ok". Debugging session should start: you will see some info in a log and debugging buttons will show up in top panel. Set breakpoint. You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#". Trigger some action in application. If you run at breakpoint, then thread should stop and you will be able to debug step by step, watch variables, etc. Limitations/Issues Because IDE doesn't have full sources, it doesn't know about class members and such. Variables watching works because most of data could be read from memory (objects in Java know about their types), but if for example, you watch an object and it has some nulled member, then you won't see, what type this member is. 9Patch Images Docs exist for the mysterious 9patch images here and there. (Read these first). These docs though are meant for developers and lack information for those who work with already compiled 3rd party applications. There you can find information how to create them, but no information about how they actually work. I will try and explain it here. The official docs miss one point that 9patch images come in two forms: source & compiled. source - You know this one. You find it in the source of an application or freely available online. These are images with a black border around them. compiled - The mysterious form found in apk files. There are no borders and the 9patch data is written into a binary chunk called npTc. You can't see or modify it easily, but Android OS can as its quicker to read. There are problems related to the above two points. You can't move 9patch images between both types without a conversion. If you try and unpack 9patch images from an apk and use it in the source of another, you will get errors during build. Also vice versa, you cannot take source 9patch images directly into an apk. 9patch binary chunk isn't recognized by modern image processing tools. So modifying the compiled image will more than likely break the npTc chunk, thus breaking the image on the device. The only solution to this problem is to easily convert between these two types. The encoder (which takes source to compiled) is built into the aapt tool and is automatically used during build. This means we only need to build a decoder which has been in apktool since v1.3.0 and is automatically ran on all 9patch images during decode. So if you want to modify 9patch images, don't do it directly. Use apktool to decode the application (including the 9patch images) and then modify the images. At that point when you build the application back, the source 9patch images will be compiled. Other FAQ What about the -j switch shown from the original YouTube videos? Read Issue 199. In short - it doesn't exist. Is it possible to run apktool on a device? Sadly not. There are some incompatibilities with SnakeYAML, java.nio and aapt Where can I download sources of apktool? From our Github or Bitbucket project. Resulting apk file is much smaller than original! Is there something missing? There are a couple of reasons that might cause this. Apktool builds unsigned apks. This means an entire directory META-INF is missing. New aapt binary. Newer versions of apktool contain a newer aapt which optimizes images differently. These points might have contributed to a smaller than normal apk There is no META-INF dir in resulting apk. Is this ok? Yes. META-INF contains apk signatures. After modifying the apk it is no longer signed. You can use -c / --copy-original to retain these signatures. However, using -c uses the original AndroidManifest.xml file, so changes to it will be lost. What do you call "magic apks"? For some reason there are apks that are built using modified build tools. These apks don't work on a regular AOSP Android build, but usually are accompanied by a modified system that can read these modified apks. Apktool cannot handle these apks, therefore they are "magic". Could I integrate apktool into my own tool? Could I modify apktool sources? Do I have to credit you? Actually the Apache License, which apktool uses, answers all these questions. Yes you can redistribute and/or modify apktool without my permission. However, if you do it would be nice to add our contributors (brut.all, iBotPeaches and JesusFreke) into your credits but it's not required. Where does apktool store its framework files? unix - $HOME/.local/share/apktool mac - $HOME/Library/apktool windows - $HOME/AppData/Local/apktool Options Utility Options that can be executed at any time. -version, --version Outputs current version. (Ex: 1.5.2) -v, --verbose Verbose output. Must be first parameter -q, --quiet Quiet output. Must be first parameter -advance, --advanced Advance usage output Decode These are all the options when decoding an apk. --api <API> The numeric api-level of the smali files to generate (defaults to targetSdkVersion) -b, --no-debug-info Prevents baksmali from writing out debug info (.local, .param, .line, etc). Preferred to use if you are comparing smali from the same APK of different versions. The line numbers and debug will change among versions, which can make DIFF reports a pain. -f, --force Force delete destination directory. Use when trying to decode to a folder that already exists --keep-broken-res - Advanced If there is an error like "Invalid Config Flags Detected. Dropping Resources...". This means that APK has a different structure then Apktool can handle. This might be a newer Android version or a random APK that doesn't match standards. Running this will allow the decode, but then you have to manually fix the folders with -ERR in them. -m, --match-original - Used for analysis Matches files closest as possible to original, but prevents rebuild. -o, --output <DIR> The name of the folder that apk gets written to -p, --frame-path <DIR> The folder location where framework files should be stored/read from -r, --no-res This will prevent the decompile of resources. This keeps the resources.arsc intact without any decode. If only editing Java (smali) then this is the recommend for faster decompile & rebuild -s, --no-src This will prevent the disassemble of the dex files. This keeps the apk classes.dex file and simply moves it during build. If your only editing the resources. This is recommended for faster decompile & rebuild -t, --frame-tag <TAG> Uses framework files tagged via <TAG> Rebuild These are all the options when building an apk. -a, --aapt <FILE> Loads aapt from the specified file location, instead of relying on path. Falls back to $PATH loading, if no file found -c, --copy-original - Will still require signature resign post API18 Copies original AndroidManifest.xml and META-INF folder into built apk -d, --debug Adds debuggable="true" to AndroidManifest file. -f, --force-all Overwrites existing files during build, reassembling the resources.arsc file and classes.dex file -o, --output <FILE> The name and location of the apk that gets written -p, --frame-path <DIR> The location where framework files are loaded from

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值