光荣在于平淡,艰巨在于漫长
前言
本来此篇当作最终篇,但是一下子写说多了,说着说着就占了很多的篇幅了,于是把这篇分拆开来当作案例分析,本篇使用的案例是联想SDK,具体的请看我的github地址…可能我写的那么多乱且没什么朋友看,但是我自己也当作是一种记录与训练,怎么把我知道的对的或者错的展现给第二个人 这是我迫切需要锻炼的能力.
Let`s going on
下面将一步一步针对ADT进行DIY,以下是一些事先需要准备的:
配置的IDE环境:android开发环境,AIR开发环境,JAVA开发环境.
配置的环境变量:android SDK tool,JDK1.7,JRE,ADT,Apktool5.2
我使用的系统:XP,Win7,Mac
SDK版本:AIRSDK:3.5,androidSDK2.2.3
案例ANE:联想支付(https://github.com/platformanes/AndroidLenovoANE)
经过前面三篇的介绍,我相信大家应该知道ADT在编译 打包 AIR FOR ANDROID项目的时候的整个工作流程,所以关于流程原理上的东西 在这里就不多赘述了,ADT编译android源码相比编译资源来说就简单很多,大家直接看源代码注释就能看明白.这一篇分析的是 ADT操作androidSD之中的dx工具把 一堆jar文件编译成dex文件的操作过程,我们都知道 每一个apk文件都需要一个dex文件,而dex文件则是可以被android设备直接执行的文件,就类似与swf文件对于flash player而言.对于想了解更多android程序原理和结构的同学,我推荐大家去购买由国内知名安全论坛看雪学院出品的一本超级好书:android软件安全与逆向分析.
不够这本书需要一定的android基础.现在我们知道dex文件便是android设备最终可执行的文件 那么我们的ADT是如何生成dex文件的呢?下面我们直接看代码.
没错今天又有东西需要补充了,其实是一个不一定会出现的问题.之前有犹豫写不写出来,但是随着接触的android SDK越多 发现其实这个问题还是蛮普遍的.
我觉得是需要差别对待.这个jar包含了android基础的几个包:
最近非常的忙,一直没怎么更新PlatformANEs，于是更新一下这四个小平台ANE。希望能帮助接这几个小平台的小伙伴.
[code lang=”java”] enjoy your code [/code]
之前介绍了ADT编译air android项目的资源,接下来介绍编译源码部分,在这之前 我会贴几张图,以说明我们在FB中开始创建 air项目 到 发布APK的整个过程,现在终于开始说编译源码的问题了,这个问题我打算从最开始的android SDK编译开始说.接下来这篇文章可能有点枯燥,但是没关系,对于我这个健忘症患者来说,如果把技术写的细致才是关键.
首先最直观的方式: 
继续阅读“解密ADT第三篇-java编译工具详解”
继前一篇介绍了android编译aapt的工具之后,可能会困惑我为什么会花一大篇文章去写一个工具怎么用,在这第二篇文章我就详细分析 ADT是怎么使用aapt来编译android资源的.
我们用原生语言java编写android程序的时候,我们仅仅需要负责编写代码 配置权限参数的工作,而编译资源 编译代码 打包apk 全部交给eclipse或者交给androidSDK的工具代劳,同样我们编写AIR for android程序也是如此 我们仅仅编写代码 其他工作都一般交给FB代劳,而FB又交给ADT代劳,而ADT则指挥android SDK的各种工具工作,这编译资源 便是 从 完成代码之后的第一步工作.下面我们看看ADT是如此操作aapt实现编译android资源的.
接触AIR将近有一年的时间,这一年里遇到很多很多的问题,从AIR FOR ANDROID 的APK签名错误,到ANE的适应所有调用原生,再到APK的加密解密反编译,然后是跨IOS/ANDROID 一路伴随AIR走来,AIR从3.4到现在的4.0,应该说见证了一些东西的发生与过程.一直以来希望找一个切入点 而形成一系列的分析文章,刚好今天临下班前突然奇想,其实我可以从分析AIR的打包工具ADT开始.于是萌发了写这篇(如果有后续的话 包括后续)文章的想法,现在第一篇我想把aapt这个工具的使用详细分析.并最终给出在写ANE过程中困扰我已久的最有效资源处理方式.
PS:为什么我会从一个工具开始说,因为ADT就像汽车一样,而aapt则是ADT的后轮的轮胎中的打气孔
一直就有朋友问我手上有没中国游戏移动基地的ANE,假期末几天有点空余,于是就update了….
在写这个ANE的过程中我深深的感受到了他的奇葩.简直把技术用到了极致,中国移动基地的SDK开发客户端现在应该为自己写出那么艰苦卓绝,那么奇形怪状,那么神来之笔,那么旋风无极,那么宇宙超级无敌屌炸天的SDK而暗暗庆幸吧.
对于这个SDK的奇怪程度足以详细写一篇博客来细细阐述.
(PS:严重提醒适用这个ANE的AIR开发者,请从SDK文档 到 我写的README 每一字每一句都仔细阅读,特别是对于我写的README)
对于AIR项目的签名类型 无论是android 还是IOS。似乎大家都只知道是.p12 也就是PKCS12类型，很多人都苦恼怎么签名和原生开发的不一样（主要是针对android）。一般android原生开发是使用JKS也就是 .keystore文件来签名。我一直以来想研究出用.p12签名文件转换成.keystor文件的方法。但是很抱歉。从.p12文件转到.keystore会缺少密匙链。当然反方向转换没什么问题。
在AIR手机游戏联合运营的今天。充斥着各种平台的签名 繁杂而讨厌。很多时候如果APK或者IPA需要自己做后台服务器更新的话 还需要去找运营商签名。严重影响更新进度。当然让运营商提供.keystore文件也可以。但是很多人只知道AIR打包只能用.p12文件签名。而使用.keystore文件似乎只有走 打包好APK再重新签的方式。其实不然。p12文件的签名方式 只是FB上限制的。在adt中已经提供了所有签名方式：
这几天更新APK 从版本v1.2升级到版本v1.3.遇到的签名冲突问题.在这里做一个记录.
A,B,C三个APK中 按照逻辑上将 A,C是应该拥有共同的签名key_A的,所以可以正常升级不会出现签名冲突;
但是事情就是这样发生了,当我安装APK_A之后安装APK_C 提示签名冲突;