前言

继前一篇介绍了android编译aapt的工具之后,可能会困惑我为什么会花一大篇文章去写一个工具怎么用,在这第二篇文章我就详细分析 ADT是怎么使用aapt来编译android资源的.

ADT编译资源

我们用原生语言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的后轮的轮胎中的打气孔

AIR Developer Tool (ADT)

AIR Developer Tool (ADT) 是用于开发 AIR 应用程序的多用途命令行工具。您可以使用 ADT 执行以下任务:
• 将 AIR 应用程序打包为 .air 安装文件
• 将 AIR 应用程序打包为本机安装程序。例如:在 Windows 上打包为 .exe 安装程序文件,在 iOS 上打包为 .ipa,或者在
Android 上打包为 .apk

最近研究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要那么多内存干什么?

继续阅读

一直就有朋友问我手上有没电信爱动漫ANE,假期末几天有点空余,于是就update了….(开场白怎么都一样..因为出发点都是这个..orz)

这是一个平淡无奇的SDK,但是细节部分很多,分别需要在不同的地方配置不同的参数.(开发这个SDK的人是SB么?明明知道自己写出来的东西是面向程序员的 还居然在不同的地方设置不同的参数配置,程序员何苦为难程序员啊~)

(PS:提醒AIR开发者,请从SDK文档 到 我写的README 每一字每一句都仔细阅读,特别是对于README)

2013-11-16

  • 更新电信爱动漫ANE
  • for android 支持android端(android 2.2以上)
  • 项目:platformANE
  • Github地址:传送门

一直就有朋友问我手上有没中国游戏移动基地的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项目的签名类型 无论是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 提供程序的默认类型。