2011~2015，5年时间，断断续续学习了Android。

  最近打算在2011年2个月认真学习的基础上，深入学习下。

  由于有之前的Android基础，加上N年的Java等变成经验，自我感觉Android应用开发还是比较简单的。

  至少相比iOS开发来说。

  

  继续坚持自己的习惯，写点自己的体会，总结自己的经验。

  学了又忘了，没啥用啊~

  

  Android打包之后，生成了APK文件。

  APK文件其实是个zip文件。

  

  比如，FileExplorer.apk，把后缀改成zip，就成了 FileExplorer.zip。

  类似的还有Excel文件，比如FansUnion.xlsx，改后缀FansUnion.zip，解压之后：

  _rels

  docProps

  xl

  [Content_Types].xml

  有兴趣的可以自己试试哦~

  

  

  

  解压之后：

  META-INF

    --CERT.RSA

--CERT.SF

--MANIFEST.MF（Java打包的程序，基本都有这个文件.最初以为和Java中的一样，后来发现不是的。）

     （1）MANIFEST.MF：这是摘要文件。程序遍历Apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码。如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。

说明：如果攻击者修改了程序的内容，有重新生成了新的摘要，那么就可以通过验证，所以这是一个非常简单的验证。

（2）CERT.SF：这是对摘要的签名文件。对前一步生成的MANIFEST.MF，使用SHA1-RSA算法，用开发者的私钥进行签名。在安装时只能使用公钥才能解密它。解密之后，将它与未加密的摘要信息（即，MANIFEST.MF文件）进行对比，如果相符，则表明内容没有被异常修改。

说明：在这一步，即使开发者修改了程序内容，并生成了新的摘要文件，但是攻击者没有开发者的私钥，所以不能生成正确的签名文件（CERT.SF）。系统在对程序进行验证的时候，用开发者公钥对不正确的签名文件进行解密，得到的结果和摘要文件（MANIFEST.MF）对应不起来，所以不能通过检验，不能成功安装文件。

（3）CERT.RSA文件中保存了公钥、所采用的加密算法等信息。

说明：系统对签名文件进行解密，所需要的公钥就是从这个文件里取出来的。

结论：从上面的总结可以看出，META-INFO里面的说那个文件环环相扣，从而保证Android程序的安全性。（只是防止开发者的程序不被攻击者修改，如果开发者的公私钥对对攻击者得到或者开发者开发出攻击程序，Android系统都无法检测出来。）

  res（各种XML资源文件）

   --drawable

   --layout

   --等等

   

   这个目录，有个特别的“战略意义”~

   上次看一篇Android文章，关于汉化的。汉化Android程序，先把APK文件解压，然后修改res资源文件，最后再次打包，再安装，

 这样就汉化了Android程序。我觉得，理论是可行的，目前没有试过。

 

 AndroidManifest.xml（Android项目的标准文件）

 

 classes.dex（Java文件最后生成的，.java->.class->.dex）

 resources.arsc(也是资源文件）

 只有那些类型为res/animator、res/anim、res/color、res/drawable（非Bitmap文件，即非.png、.9.png、.jpg、.gif文件）、

 res/layout、res/menu、res/values和res/xml的资源文件均会从文本格式的XML文件编译成二进制格式的XML文件。

 好处应该是效率。

 

 参考资料：

  Android签名与认证详细分析之一（CERT.RSA剖析）

http://myeyeofjava.iteye.com/blog/2125348

 Android应用程序资源的编译和打包过程分析

 http://www.cnblogs.com/mfryf/archive/2013/05/21/3090844.html

 

 

 小雷FansUnion--一个正在学习Android的程序员