前言
之前介绍了ADT编译air android项目的资源,接下来介绍编译源码部分,在这之前 我会贴几张图,以说明我们在FB中开始创建 air项目 到 发布APK的整个过程,现在终于开始说编译源码的问题了,这个问题我打算从最开始的android SDK编译开始说.接下来这篇文章可能有点枯燥,但是没关系,对于我这个健忘症患者来说,如果把技术写的细致才是关键.
- FB打包APK 过程剖析
首先最直观的方式: 
继续阅读“解密ADT第三篇-java编译工具详解”
解密ADT第二篇-编译APK资源
前言
继前一篇介绍了android编译aapt的工具之后,可能会困惑我为什么会花一大篇文章去写一个工具怎么用,在这第二篇文章我就详细分析 ADT是怎么使用aapt来编译android资源的.
ADT编译资源
我们用原生语言java编写android程序的时候,我们仅仅需要负责编写代码 配置权限参数的工作,而编译资源 编译代码 打包apk 全部交给eclipse或者交给androidSDK的工具代劳,同样我们编写AIR for android程序也是如此 我们仅仅编写代码 其他工作都一般交给FB代劳,而FB又交给ADT代劳,而ADT则指挥android SDK的各种工具工作,这编译资源 便是 从 完成代码之后的第一步工作.下面我们看看ADT是如此操作aapt实现编译android资源的.
解密ADT第一篇-aapt详解
我的出发点
接触AIR将近有一年的时间,这一年里遇到很多很多的问题,从AIR FOR ANDROID 的APK签名错误,到ANE的适应所有调用原生,再到APK的加密解密反编译,然后是跨IOS/ANDROID 一路伴随AIR走来,AIR从3.4到现在的4.0,应该说见证了一些东西的发生与过程.一直以来希望找一个切入点 而形成一系列的分析文章,刚好今天临下班前突然奇想,其实我可以从分析AIR的打包工具ADT开始.于是萌发了写这篇(如果有后续的话 包括后续)文章的想法,现在第一篇我想把aapt这个工具的使用详细分析.并最终给出在写ANE过程中困扰我已久的最有效资源处理方式.
PS:为什么我会从一个工具开始说,因为ADT就像汽车一样,而aapt则是ADT的后轮的轮胎中的打气孔
AIR Developer Tool (ADT)
AIR Developer Tool (ADT) 是用于开发 AIR 应用程序的多用途命令行工具。您可以使用 ADT 执行以下任务：
• 将 AIR 应用程序打包为 .air 安装文件
• 将 AIR 应用程序打包为本机安装程序。例如：在 Windows 上打包为 .exe 安装程序文件，在 iOS 上打包为 .ipa，或者在
Android 上打包为 .apk
Flascc与IOS打包IPA
最近研究Flascc顺道应用到AIR for IOS项目中，发现Flascc编译的优化等级与打包IPA有着非常大的关系
首先是一个老外先发现的：传送门
AIR 打包IPA
先说说AIR for IOS打包，打包限制发行版和发行版 官方文档说需要多一点时间，其实那里止需要多一点时间啊，除了时间需要多一点以外（4G内存版MAC 需要15分钟以上），还需要配置64位的机子 4G以上内存，32位的别想打包IPA顺畅了（注意 是顺畅 不是不能），翻看JAVA虚拟机LVM官方解释是 32位的虚拟机限制到1.5G的内存，而64位的JDK则不限制内存，而AIR 打包IPA的时候虚拟机内存一路飙升，我一开始使用32位+4G内存打包的时候 打开内存查看器看到java.exe所占内存一路高歌 直到爆掉。不禁让人唏嘘，请问adobe打包个ipa要那么多内存干什么？
[PlatformANEs]更新电信爱动漫ANE( for android)
一直就有朋友问我手上有没电信爱动漫ANE,假期末几天有点空余,于是就update了….(开场白怎么都一样..因为出发点都是这个..orz)
这是一个平淡无奇的SDK,但是细节部分很多,分别需要在不同的地方配置不同的参数.(开发这个SDK的人是SB么?明明知道自己写出来的东西是面向程序员的 还居然在不同的地方设置不同的参数配置,程序员何苦为难程序员啊~)
(PS:提醒AIR开发者,请从SDK文档 到 我写的README 每一字每一句都仔细阅读,特别是对于README)
2013-11-16
- 更新电信爱动漫ANE
- for android 支持android端(android 2.2以上)
- 项目:platformANE
- Github地址:传送门
[PlatformANEs]更新中国移动游戏基地ANE( for android)
一直就有朋友问我手上有没中国游戏移动基地的ANE,假期末几天有点空余,于是就update了….
在写这个ANE的过程中我深深的感受到了他的奇葩.简直把技术用到了极致,中国移动基地的SDK开发客户端现在应该为自己写出那么艰苦卓绝,那么奇形怪状,那么神来之笔,那么旋风无极,那么宇宙超级无敌屌炸天的SDK而暗暗庆幸吧.
对于这个SDK的奇怪程度足以详细写一篇博客来细细阐述.
(PS:严重提醒适用这个ANE的AIR开发者,请从SDK文档 到 我写的README 每一字每一句都仔细阅读,特别是对于我写的README)
2013-11-10
- 更新中国移动游戏基地ANE
- for android 支持android端(android 2.2以上)
- 项目:platformANE
- Github地址:传送门
[AIR]签名类型.P12与.keystore
对于AIR项目的签名类型 无论是android 还是IOS。似乎大家都只知道是.p12 也就是PKCS12类型，很多人都苦恼怎么签名和原生开发的不一样（主要是针对android）。一般android原生开发是使用JKS也就是 .keystore文件来签名。我一直以来想研究出用.p12签名文件转换成.keystor文件的方法。但是很抱歉。从.p12文件转到.keystore会缺少密匙链。当然反方向转换没什么问题。
在AIR手机游戏联合运营的今天。充斥着各种平台的签名 繁杂而讨厌。很多时候如果APK或者IPA需要自己做后台服务器更新的话 还需要去找运营商签名。严重影响更新进度。当然让运营商提供.keystore文件也可以。但是很多人只知道AIR打包只能用.p12文件签名。而使用.keystore文件似乎只有走 打包好APK再重新签的方式。其实不然。p12文件的签名方式 只是FB上限制的。在adt中已经提供了所有签名方式：
-storetype keystore 的类型，由 keystore 实现确定。大多数 Java 安装随附的默认 keystore 实现支持 JKS 和 PKCS12 类型。
Java 5.0 包含对 PKCS11 类型和 Keychain 类型的支持，前者用于访问硬件标记中的 keystore，后者用于访问 Mac OS X
keychain。Java 6.0 包含对 MSCAPI 类型的支持（在 Windows 中）。如果安装和配置了其他 JCA 提供程序，则可能还可以
使用其他 keystore 类型。如果未指定任何 keystore 类型，则使用默认 JCA 提供程序的默认类型。
[mac]关于这几天svn的折腾
首先我很讨厌svn。讨厌到不能再讨厌它了。虽然我在团队里面负责配置svn 服务器 客户端 负责每一个人的svn帐号，负责整个版本管理。我一直在问自己为什么不改用git呢。关于git的好处我可以说一上午，但是无论我说再多，用惯了svn的同事们还是无屑一顾。因为关于他们认为svn的好处 他们也可以说一上午，虽然我认为与git相比简直不值一提。
而我现在要做的是在MAC中配置SVN客户端环境
首先检查本机svn版本 发现是 1.6。
[code lang=”java”]
svn –version
[/code]
而我svn服务器我当初记得配置的是1.7以上的。按照以往给同事配svn的经验 mac上的svn必须更新。否则肯定没戏。事实验证也是如此：
[code lang=”java”]
svn checkout https://xxx.xxx.xxx.xxx/svn/myproject
–username=rect –password=123 /user/rect/myproject
[/code]
自然报出svn版本过低的问题，于是乎只能升级svn了。
各自的解决方式本身没什么问题。问题在于svn版本的改变。
[ANE for IOS]iOS自定义URL方案解析
在ios中程序间互相调用可以通过url来解决。在oc里面直接在函数handleOpenURL 便可，但是在ane中就没那么简单了。下面详细介绍下air项目中url的设置和使用，使用支付宝快捷支付ane作为例子。网上有稀稀疏疏的几篇文章偶尔提及,但是并没有完全给出一个DEMO来.
在此之前请详细阅读官方文档：传送门
关于打开URL的ANE例子:传送门
IOS里OC的处理方式:传送门
在AIR中配置URL供其他程序调用
1.首先需要在-app.xml中加入如下配置:([IPHONE]标签中)
[code lang=”java”]
<iPhone>
<InfoAdditions><![CDATA[
<key>UIDeviceFamily</key>
<array>
<string>1</string>
<string>2</string>
</array>
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>AlipayANE</string>
</array>
<key>CFBundleURLName</key>
<string>com.rect.app</string>
</dict>
</array>
]]></InfoAdditions>
<requestedDisplayResolution>high</requestedDisplayResolution>
</iPhone>
[/code]
在这类配置了一个Name为”com.rect.app”的Schemes.调用方式为”AlipayANE://”;
[Android]关于APK签名冲突问题的记录
这几天更新APK 从版本v1.2升级到版本v1.3.遇到的签名冲突问题.在这里做一个记录.
问题重现
- APK_A:目前平台上玩家的版本v1.2 拥有平台签名 key_A;(md5算法)
- APK_B:我方(开发商)提供的新版本v1.3 给平台方签名,拥有我方签名 key_B;(RSA,SHA1,MD5)
- APK_C:平台方签名后返回的新版v1.3已签名包,拥有平台签名 key_A;
A,B,C三个APK中 按照逻辑上将 A,C是应该拥有共同的签名key_A的,所以可以正常升级不会出现签名冲突;
但是事情就是这样发生了,当我安装APK_A之后安装APK_C 提示签名冲突;
原因分析
- 平台方两次的签名key_A 被篡改;
- 平台方两次签名工具差异导致的签名不成功(包括版本差异);
- 平台方签名命令行两次发生变化,例如新增了某算法验证;
- 平台方未去除干净key,就签名,等于是二次签名
- 我方提供的签名key_B 对key_A产生影响;