SDK(Software Development Kit)是软件开发工具包的缩写,一般来说,SDK是用于给开发人员提供进行应用程序开发的工具的,这样程序员就可以快速的开发出应用软件,省去了编写硬件代码和基础代码框架的过程,我们常见的Android SDK就属于这一类。除了这种比较大的SDK,我们平时开发的library也属性SDK,只不过功能比较单一,适用的场合也比较简单,如短视频SDK、推送SDK,分享SDK等。 而我们所做的游戏SDK主要是用于第三方游戏开发接入我们的账号体系和支付体系,类似于友盟分享等聚合SDK。
在游戏行业中,会存在两个最基本的角色,即游戏开发和游戏运营,一个游戏能不能成功,除了技术体验好之外,运营是一门很重要的学问,他们的关系如下图所示。
正如前面说描述的一样,游戏和运营往往是单独开来的,除非像腾讯、网易这些头部大公司,不仅可以自己研发游戏,还有实力自己推广和运营游戏。不过,事实上,很多小的游戏开发商就那么几个人或者几十个人,根本没有自己的运营能力,而市面上正好有专业的游戏运营公司,这时候它们就开始合作了。
在上面的图例中,小红是做社交App的娱乐公司,日活几千万,想让自己平台多元化,比如做个游戏下载的功能,给用户下载,用户觉得好玩,可能就会付费买装备,但是有个问题,小红并不会做游戏,如果单开一个产品线去研发游戏,投入是相当巨大的,所以想到能不能去外面接游戏进来。
游戏SDK最核心的功能就是登录和支付,其它都是一些运营相关的,例如埋点、数据统计、崩溃等等。其中,登录的流程大体如下。
而支付的流程大体是先SDK,然后再通知游戏支付结构,流程如下所示。
游戏SDK作为基础SDK,通常需要遵循一些基本的开发规范,例如,尽量少用第三方库、减少对外接口、明确技术文档等。
作为SDK,我们应该尽量少使用开源库或者说不用开源库,尽量直接使用系统提供的库,实在不行也可以手写网络框架,手写数据库等等,主要基于以下两个方面考虑。
当然,依赖库并不是说不能用,有时候一些数据统计的库就需要依赖第三方库,那么对于这种情况冲突是不可避免的,通常解决冲突有两种常见的手段。
强制使用某个版本,例如:
configurations.all {
resolutionStrategy {
force 'com.android.support:support-v4:26.1.0' //解决v4包冲突,强制使用这个版本的v4包
}
}
很多做应用开发的都知道,如果一个项目中重复使用了某个库,那么可以使用exclude排除某个依赖,如下:
implementation("com.xxx.xxx:xx") {
exclude group: 'com.android.support'
}
exclude是最常用的解决依赖冲突的方式,但如果多个依赖库引入不同版本的其它库,需要分别写好多个exclude,显然第一种方式比较简单粗暴。
对于SDK开发,对外的接口尽量越少越好。以游戏SDK为例,对外暴露的接口一般有SDK初始化、登录、支付等,如下所示。
定义接口
interface IGame {
// 1、在Application中调用,
fun registerApp(context: ApplicationContext, appId: String)
// 2、在activity中初始化
fun init(activity: Activity)
// 3、业务接口,登录、支付等等
fun login(loginCallBack: LoginCallBack)
fun pay(product: Product, payCallBack: PayCallBack)
...
}
接口实现:
class GameImpl : IGame{
override fun registerApp(context: ApplicationContext, appId: String) {
//appid相关
}
override fun init(activity: Activity) {
//初始化逻辑,例如显示悬浮窗
}
override fun login(loginCallBack: LoginCallBack) {
//登录逻辑
}
override fun pay(product: Product, payCallBack: PayCallBack) {
//支付逻辑
}
...
}
实现类是我们SDK内部的处理逻辑,我们不希望被外部访问到,外部只需要知道有 IGame这个接口中的方法就行,因此,我们可以再写个单例的管理类来给外部使用,如下所示。
/**
* 单例的SDK管理类
*/
object GameSDKManager :IGame{
//实现类私有化
private val gameImpl: IGame by lazy { GameImpl() }
override fun registerApp(application: Application, appId: String) {
gameImpl.registerApp(application,appId)
}
override fun init(activity: Activity) {
gameImpl.init(activity)
}
override fun login(loginCallBack: LoginCallBack) {
gameImpl.login(loginCallBack)
}
override fun pay(product: Product, payCallBack: PayCallBack) {
gameImpl.pay(product,payCallBack)
}
}
实际使用时,外部通过GameSDKManager.xxx来调用SDK中的方法,以后要提供其它方法,只要修改 IGame接口,然后在 GameSDKManager 和 GameImpl 类中分别进行实现即可。
游戏SDK开发相比应用开发来说,技术难度一般不大,问题大多出在跟游戏对接的时候。可能会出现一些问题, 比如ClassNotFound、Resource not found、依赖冲突、崩溃等等,对于这类问题,我们需要先分析问题的原因,然后确认由谁负责,最后确定修改方案。
和应用开发不同,很多游戏还是使用Eclipse进行开发的,所以在对接游戏时需要提供Eclipse版本。需要说明的是,Eclipse 不能使用Android Studio版本的SDK,搭建Eclipse的Android环境需要使用ADT插件,具体怎么使用请参考官网。
由于SDK的产物是aar,而Eclipse只能依赖jar包和library,一般都用jar包依赖,因此先将aar解压出来,把里面的classes.jar拷贝出来重命名,然后在Eclipse中依赖这个jar包,同时SDK的资源文件、libs目录下的jar包也需要拷贝到Eclipse项目中。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_test)
}
上面的代码是一段再常见不过的代码了,但是这段代码在打包aar的时候,Android Studio接入没问题,但是打成jar包,Eclipse接入的时候会奔溃,日志如下:
Caused by: android.content.res.Resources$NotFoundException: Resource ID #0x13d6b6
at android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:246)
at android.content.res.Resources.loadXmlResourceParser(Resources.java:2256)
at android.content.res.Resources.getLayout(Resources.java:1228)
at android.view.LayoutInflater.inflate(LayoutInflater.java:427)
at android.view.LayoutInflater.inflate(LayoutInflater.java:380)
at androidx.appcompat.app.AppCompatDelegateImpl.setContentView(AppCompatDelegateImpl.java:555)
at androidx.appcompat.app.AppCompatActivity.setContentView(AppCompatActivity.java:161)
at luyao.util.ktx.base.BaseVMActivity.onCreate(BaseVMActivity.kt:25)
我们打开源代码文件,然后将鼠标放到R.layout.activity_test上,如下图所示。
搞过Android开发的同学都知道,上面的常量是在AAPT打包的阶段生成的,是一个R常量。对于Android工程是如何打包的,下面让我们来简单的回顾下流程:
Android的打包流程可以查看:Android打包流程 apk编译的第一个阶段,AAPT会打包资源文件,生成R.class文件和resources.arsc资源索引表。对于library项目,在打包aar的时候,aar中并不需要生成 resources.arsc 资源索引表,资源的id跟资源文件的映射关系记录在R.txt中,如下图所示。
Eclipse因为只能接入jar包,也就是解压aar后取出里面的classes.jar,当我们把资源文件拷贝到Eclipse,再编译apk的时候,资源文件会对应一个新的资源id,而aar中classes.jar里引用的资源id是不变的,所以就会出现上面的问题。
知道这个问题后,要解决这个问题,那么SDK里面使用资源id就需要动态去获取,不能使用R文件里面的常量。
谷歌提供了相关的API(getIdentifier),可以通过资源名称获取资源id,getIdentifier的源码如下。
/**
* Return a resource identifier for the given resource name. A fully
* qualified resource name is of the form "package:type/entry". The first
* two components (package and type) are optional if defType and
* defPackage, respectively, are specified here.
*
* <p>Note: use of this function is discouraged. It is much more
* efficient to retrieve resources by identifier than by name.
*
* @param name The name of the desired resource.
* @param defType Optional default resource type to find, if "type/" is
* not included in the name. Can be null to require an
* explicit type.
* @param defPackage Optional default package to find, if "package:" is
* not included in the name. Can be null to require an
* explicit package.
*
* @return int The associated resource identifier. Returns 0 if no such
* resource was found. (0 is not a valid resource ID.)
*/
public int getIdentifier(String name, String defType, String defPackage) {
return mResourcesImpl.getIdentifier(name, defType, defPackage);
}
其中,第一个参数是资源名称,如一个TextView定义的id叫tv_title;第二个参数是类型,如 string、xml、style、layout 等等,跟R.class文件里面的内部类是对应的;第三个参数是应用的包名。例如,下面是第二个参数的R文件对应。
为了方便动态获取资源的Id,我们可以封装个工具,如下所示:
object ResourceUtil {
//缓存资源id
private val idMap: HashMap<String, Int> = HashMap()
private fun getIdByName(context: Context, defType: String, name: String): Int {
//缓存
val key = defType + "_" + name
val value: Int? = idMap.get(key)
value?.let {
return it
}
//获取资源id
val identifier = context.resources.getIdentifier(name, defType, context.packageName)
identifier?.let {
idMap.put(key, identifier)
}
return identifier
}
/**
* 获取布局文件的资源ID,defType传 layout
*/
fun getIdFromLayout(context: Context, name: String): Int {
return getIdByName(context, "layout", name)
}
...
然后,我们将setContentView(R.layout.test) 需要修改成如下的方式即可。
setContentView(ResourceUtil.getIdFromLayout(context, "test"))
以下是Android 官网给的apk的打包流程,如下下图所示。
在apk编译的第一个阶段,需要使用AAPT(Android Asset Packaging Tool缩写)打包资源文件,产物如下。
我们需要重点关注的是资源索引表 resources.arsc,resources.arsc 文件的数据格式比较复杂,我们可以将apk文件拖到Android Studio中,然后选择 resources.arsc打开,如下图所示。
可以发现,resources.arsc文件会包含很多的资源索引,打开layoyt文件,会发现该文件 主要由id(资源id)、name(资源名称)、value(资源路径)都可以通过这个索引表来互相转换,前面说过 Resources#getIdentifier(String name, String defType, String defPackage),之所以可以通过资源名称获取到资源id,当然还是要借助 resources.arsc 这个资源索引表。
如果是普通的游戏SDK,那么只要保证接入方能够成功接入SDK就完事了。然而,游戏SDK的支持还需要对接入游戏SDK的游戏进行验收,确保游戏SDK的功能正常,能够正常提交应用市场。并且,随着SDK的版本升级,功能会增加,需要验收的功能会越来越多,例如:验证签名,SDK有检查更新的功能,token过期,游戏需要做退出登录逻辑等等。下面是游戏SDK支持的一些场景和处理方式,以及经验分享。
众所周知,不管是应用开发还是SDK开发,release版本一般都是关闭了日志的,我们需要使用日志复现问题,常用的有两种方式:
有时候,我们提供的Demo工程是运行是正常的,但是第三方游戏接入的时候经常会出现一些问题,可能是他们的Android SDK版本不一样,或者一些配置没有严格按照文档来写,作为SDK的开发者,我希望这些配置的问题接入方可以自己发现和处理,这就需要在游戏SDK中增加检测的逻辑。
从Android 8.0 版本开始,调起应用安装页面需要用户显式打开未知来源开关,下面是系统的相关检察源码。
对于这个问题,首先想到是接入方没有声明安装权限,如下。
<!--安装apk需要的权限-->
<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
然后,我们去掉权限声明验证发现还是会抛异常,说明不是这个原因。最后,经过分析发现当 targetSdkVersion 小于26的话, packageManager.canRequestPackageInstalls()一直会返回false,所以各大应用市场已经陆续要求targetSdkVersion必须26或以上,为了保证SDK的更新功能正常,在SDK初始化的时候,添加如下检测代码。
由于 7.0之后安装apk需要通过FileProvider来获取url,所以需要在Manifest.xml添加如下代码。
如果是Android Studio打包,一般会自动读取build.gradle中的_PACKAGENAME_的值来替换占位符_PACKAGENAME_的数据,如果是Eclipse打包,占位符_PACKAGENAME_则原封不动,不会被替换。不管使用Eclipse打包就会报一个空指针,如下所示是Eclipse代码。
FileProvider.getUriForFile(context,
context.packageName + ".fileprovider", file)
那如何保证接入方一定有配置FileProvider,并且配置正确呢?我们可以增加配置检测如下代码。
在上面的代码中,我们可以在sdk初始化的时候去私有目录创建一个空文件,然后通过 getUriFormFile 方法触发FileProvider获取url的逻辑,如果有异常则说明FileProvider配置不对,直接给出错误信息。
游戏方接入游戏SDK之后打包成apk,这个apk需要在我们平台上线,我们希望统一apk签名, 所以在验收apk的时候还需要确认apk的签名。要查看apk签名,我们可以使用命令行和工具两种方式。查看签名的命令如下:
v2签名
keytool -printcert -jarfile xxx.apk
或者
apksigner verify -v --print-certs xxx.apk
v1签名 如果apk是使用v1签名,那么比较麻烦,首先需要解压apk,找到META-INFO目录下的 CERT.RSA,然后执行如下命令。
keytool -printcert -file CERT.RSA
除了使用命令方式外,我们还可以使用工具来察看,如macOS的fHash等软件,将apk文件拖到软件中即可,如下所示。
做过Android应用开发的同学对于渠道包肯定不会陌生,由于Android应用市场众多,如果要上不同的应用市场,那么就需要打不同的渠道包。Android多渠道包除了可以使用Gradle多渠道打包外,还可以使用美团Walle、友盟等多渠道工具进行多渠道打包。
不管,对于游戏SDK来说,单纯使用Walle并不适合,因为大部分游戏发行商,默认的apk签名方式都是v1签名。参考过大多数的游戏渠道分发公司,基本都是使用打包脚本进行打包,并且打包脚本一般使用python开发。
Android v1的签名是基于JAR 的,签名jar Signature来自JDK,Android v2的签名是基于APK Signature Scheme v2,是Android 7.0版本引入的,而最新的v2是对v2版本的优化,适用于Android 9.0及以上版本 。它们的区别如下:
众所周知,apk文件其实就是一个带签名信息的zip文件,根据zip文件格式规范,zip文件末尾有一部分元数据代表zip文件注释,正确修改这一部分数据不会对zip文件造成破坏,如下所示。
针对v1签名,还有其它渠道包打包方案,但是大部分都存在效率问题,例如利用gradle的productFlavors属性打渠道包,速度慢;或者利用META-INF目录不被签名校验的特点,加入文件名为渠道名的空文件,但是读取渠道的时候比较慢,因为需要解压apk,涉及文件的读取。
V2签名块中有个区块可以添加一些附属信息,并且不会被签名校验,将自定义渠道信息写入这个区块,生成渠道包。可以参考下美团Walle。正如前文所说,我们使用的python打包脚本,应该不存在上面的问题。
在Android逆向工程中,有一个很重要的工具,那就是Apktool。首先,我们到Apktool官网下载下工具,当然我们也可以从其他地方进行下载。下载apktool.jar、apktool可执行脚本,放到 /usr/local/bin/ 目录下,然后 command + x 设置权限就可以了。
然后,我们使用apktool d命令反编译apk文件,如下所示。
apktool d demo.apk
其中,如果不指定目录那么默认会输出到原目录,如果需要指定目录,那么可以使用-o 参数来指定输出目录。反编译之后,接下来就可以修改资源文件或者字节码。
修改资源文件或者字节码文件后,我们需要回编译包,回编译的命令如下。
apktool b demo -o unsign.apk
不过,上面的输出的是未签名的apk,需要签名才能安装到手机上。
对于Android应用开发来说,可以直接使用Android Studio来制作一个签名文件。但是,单独给一个未签名的apk签名,就需要借助签名工具,v1签名是使用jarsigner,v2签名是使用apksigner。其中,v1签名的命令如下:
jarsigner -verbose
-keystore [签名文件路径]
-keypass [密码]
-storepass [密码]
-signedjar [输出apk路径] [需要签名的apk路径]
-digestalg [摘要算法的名称如SHA1]
-sigalg [签名算法的名称如MD5withRSA]
[证书别名]
例如,我有一个签名文件叫 demo.keystore,别名密码都是 123456,那么签名命令如下。
jarsigner -verbose -keystore demo.keystore -keypass 123456 -storepass 123456 -signedjar sign.apk unsign.apk -digestalg SHA1 -sigalg MD5withRSA 123456
如果需要使用v2 签名,由于v2签名使用的是apkSigner,在SDK build-tools下,注意在版本25以上才有。
使用apkSigner签名的命令如下所示。
apksigner sign
--ks [签名文件]
--ks-pass pass:[密码]
--out [输出apk路径]
[需要签名的apk]
例如,签名文件叫 demo.keystore,别名密码都是 123456,那么apkSigner签名命令如下。
apksigner sign --ks demo.keystore --ks-pass pass:123456 --out sign_v2.apk unsign.apk
apksigner 签名过程没有任何提示,可以结合验证签名命令一起使用,如下所示。
apksigner verify -v --print-certs sign_v2.apk
到此,Android 游戏SDK相关的开发和渠道包相关的就介绍完了,后面回对打包遇到的一些问题进行补充,如果你对游戏联运有兴趣,也欢迎留言交流。