分类目录归档:Android

Sublime Android Studio Logcat 高亮语法插件

Published / by sickworm / Sublime Android Studio Logcat 高亮语法插件有1条评论

网上找的都是旧的 Logcat 格式,Android Studio 日志格式不适配。于是自己改了一个:

https://gist.github.com/sickworm/8ae911809f29c38767171767aed2ed3d

支持且仅支持 Android Studio 默认格式,e.g.:

2019-07-25 10:26:17.145 21794-21794/com.sickworm.test I/XXXView: hello I am a log

使用方法:
点击 Preferences -> Browse Packages(Windows)或 Sublime Text -> Preferences -> Browse Packages(Mac),把上面的文件扔进 User 文件夹中,重启,打开日志文件,右下角选择 Logcat (Android Studio)。

默认识别 *.log, *.logcat。

PS:上面的是编译后的文件,原文件:

https://gist.github.com/sickworm/f08a28b276f5e5a169908604b5d8e930

教程:(需要 Sublime 安装 PackageDev 包)
http://docs.sublimetext.info/en/latest/extensibility/syntaxdefs.html#your-first-syntax-definition

配色选择:

https://www.sublimetext.com/docs/3/scope_naming.html#string

版权所有,转载请注明出处:
https://sickworm.com/?p=1689

给 Android ROM(AOSP)集成 SuperSU 的方法

Published / by sickworm / 给 Android ROM(AOSP)集成 SuperSU 的方法有4条评论

本文实验配置:

ROM: AOSP Android-6.0.1_r77
设备:Nexus 5
SuperSU: SR5-SuperSU-v2.82-SR5-20171001224502.zip

SuperSU 官方下载链接:https://download.chainfire.eu/1220/SuperSU/

处理 SELinux

我们给 Android 编译 ROM 的时候,可以编译出带有 root 权限的版本。但是由于 Android 4.4 以上 SELinux 的存在,apk 还是无法获得 root 权限,这样很多 root app 都会提示无法获取 root,不能正常使用了。想要 apk 可获得 root 权限,有两种方法:

  1. 关闭 SELinux 监控
  2. 配置 SELinux 权限

由于方案 2 需要熟悉复杂的 selinux 权限模型,而且我在实验过程中按网上办法硬是配置不上 domain(提示我没有设置 domain。有可能是因为我没有清空输出物,但不确定),所以我最后使用了方案 1。办法是在 $YOUR_AOSP/device/$YOUR_RAND/$YOUR_DEVICE/BoardConfig.mk 中的 BOARD_KERNEL_CMDLINE := xxxx下方加上:

BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive

这样就可以使 SELinux 不阻止你的操作了,permissive 只会打日志不会做实际动作,disabled 是完全关闭。注意加上这个后会通过不了 Google 的 CTS 测试,如果你是厂家的话需要注意这一点,个人开发者不需要关心。

当然,启动完成后进入 shell,以 root 权限执行 setenforce 0 也是可以达到关闭 SELinux 监控的效果。但每次重启都要设置一遍,比较麻烦。

好了,关闭 SELinux 了。但此时你用 apk 尝试获取 root 权限,发现还是不行。因为 AOSP 的 su 是只能 shell 或者 root 用的。解决办法是:

  1. 注释掉 system/extras/su/su.c 中 main 的一行 “not allow” 的代码,这行代码会判断 uid。注释后重新 make 一次 su 就能正常使用了
  2. 使用非 AOSP 的 su,SuperSU 提供的 su 需要配合 SuperSU 其他文件,不能直接用。

然后我发现改了 su 还是不行。。我猜测 framework 层可能还有权限处理机制,那我再给 rom 集成 SuperSU 授权管理,这样总可以了把。当然你也可以每次刷 rom 后重新刷一遍第三方 recovery,再刷一遍 SuperSU。这个集成我搞了 2 天才完成,网上资料不多,而且没一个能用。。

这里提一点,如果不搞好 SELinux,集成了 SuperSU 也是没法用的。如果你不想使用方案 2,我提供几篇文章以供参考:

Compile Android 5.1.1 ROM with ROOT by SuperSU

这篇没有配置 init.rc 里面的 service 的 SELinux domain。反正我不行。

init 启动 Native Service 时出现Service xxxx needs a SELinux domain defined; please fix 警告的说明
[Android][L][SELinux]Define a SELinux domain for Service

这 2 篇教你如何配置 SELinux domain。我配置完了还是说我没配置:“init 启动 Native Service 时出现Service xxxx needs a SELinux domain defined; please fix”。上面我也提到了,可能我没 clean/clobber 才失败的,如果你尝试成功了,不妨也告诉我。

实现 SELinux | AOSP

这是 AOSP 官方对 SELinux 的介绍,在这个问题里我没看到更多的信息。

集成 SuperSU

上面这篇文章Compile Android 5.1.1 ROM with ROOT by SuperSU 也提到了集成 SuperSU 的步骤。可惜日月变迁,现在 SuperSU 已经不是单一个 su 运作了。通过翻看 SuperSU 的指南 How-To SU,我得到几个信息:

  1. 最少需要这 4 个文件,就可以保证 SuperSU 正常运行:
    /system/xbin/su
    /system/xbin/daemonsu
    /system/xbin/supolicy
    /system/lib(64)/libsupol.so
    
  2. 需要在开机时执行 daemonsu --auto-daemon,启动守护进程。

  3. 执行 daemonsu --auto-daemon 时会调用 supolicy ,然后调用 libsupol.so。用于配置 SuperSU 的 SELinux 权限。

通过翻看 SuperSU 的刷 recovery 的包里的 update-binary.sh 我得到几个信息:

  1. daemonsu 和 su 是同一个文件

  2. 开机执行 daemonsu --auto-daemon 的方法有好几种,如果有 /system/int/init.d/ 这个文件夹(我没有)就放一个脚本进去,不然就是劫持 /system/bin/app_process(64),或是给 /system/放一个 install-recovery.sh。原文 Furthermore, daemonsu --auto-daemon needs to be launched somehow on boot. This is generally done via install-recovery.sh, 99SuperSUDaemon, or hijacking app_process([32|64]).

最后这条信息告诉我们 SuperSU 不需要关闭 SELinux 也可以使用,也告诉我们集成 SELinux 而不关闭 SELinux 的办法。方法 1 由于我手机没有,所以不用;2 劫持 app_process 那个是把 app_process 链接给了 su,具体我没看懂;3 install-recovery.sh 这个文件是刷 recovery 的时候会产生的,当系统启动的时候就会执行到它,刷完就会删掉这个文件。SuperSU 利用了这个特性,在 install-recovery.sh 里执行了daemonsu --auto-daemon,而且这个文件一直存在。因为执行 install-recovery.sh 对应的是 flash_recovery 的 SELinux domain,是已经配置好的。SuperSU 通过这三种方法来绕过 SELinux,然后再通过 sepolicy 来修改 SELinux 配置。

而我这边因为一直都是配置在 init.rc 里,且关闭了 SELinux,所以没有用到上面提到的方案。

集成步骤(在 Compile Android 5.1.1 ROM with ROOT by SuperSU 基础上修改)

  1. 删除原 su。文件位置 system\extras\su,最简单的方法是把该目录下的 Android.mk 重命名或者删掉。

  2. 添加 SuperSU 相关文件。包括上面提到的 4个 Linux 文件,和一个 SuperSU.apk。Linux 文件我选择在 packages 下新建了一个 su,放入上面那4个文件,以及创建 Android.mk。我比较懒,就没有做架构选择,就只把自己的 Nexus 5 对应的 armv7 包里的文件拷过来了,suinit 和 sukernel 不需要,复制一份 su 改名为 daemonsu。Android.mk 内容如下:

    LOCAL_PATH := $(call my-dir)
    
    include $(CLEAR_VARS)
    
    LOCAL_MODULE_TAGS := optional
    LOCAL_MODULE := su
    LOCAL_SRC_FILES := $(LOCAL_MODULE)
    LOCAL_MODULE_CLASS := EXECUTABLES
    LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)
    LOCAL_UNSTRIPPED_PATH := $(LOCAL_MODULE_PATH)
    include $(BUILD_PREBUILT)
    
    
    include $(CLEAR_VARS)
    
    LOCAL_MODULE_TAGS := optional
    LOCAL_MODULE := daemonsu
    LOCAL_SRC_FILES := $(LOCAL_MODULE)
    LOCAL_MODULE_CLASS := EXECUTABLES
    LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)
    LOCAL_UNSTRIPPED_PATH := $(LOCAL_MODULE_PATH)
    include $(BUILD_PREBUILT)
    
    
    include $(CLEAR_VARS)
    
    LOCAL_MODULE_TAGS := optional
    LOCAL_MODULE := supolicy
    LOCAL_SRC_FILES := $(LOCAL_MODULE)
    LOCAL_MODULE_CLASS := EXECUTABLES
    LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)
    LOCAL_UNSTRIPPED_PATH := $(LOCAL_MODULE_PATH)
    include $(BUILD_PREBUILT)
    
    
    include $(CLEAR_VARS)
    
    LOCAL_MODULE_TAGS := optional
    LOCAL_MODULE := libsupol.so
    LOCAL_MODULE_CLASS := SHARED_LIBRARIES
    LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)
    LOCAL_SRC_FILES := $(LOCAL_MODULE)
    OVERRIDE_BUILD_MODULE_PATH := $(TARGET_OUT_INTERMEDIATE_LIBRARIES)
    include $(BUILD_PREBUILT)
    

    apk 我放在了 packages/apps/SuperSU,同样的,放入 Superuser.apk(上面的官方刷机包里有),同时创建 Android.mk,内容如下:

    LOCAL_PATH := $(call my-dir)
    include $(CLEAR_VARS)
    
    LOCAL_MODULE := SuperSU
    
    LOCAL_SRC_FILES := Superuser.apk
    LOCAL_MODULE_CLASS := APPS
    LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
    LOCAL_CERTIFICATE := PRESIGNED
    
    include $(BUILD_PREBUILT)
    
  3. 把第 2 步添加的 packages 添加到编译路径中。我只给 Nexus 5 设备添加了(这样不好,因为第一步把所有设备的 su 都删掉了)。修改 $YOUR_AOSP/device/$YOUR_RAND/$YOUR_DEVICE/device.mk,添加:
    PRODUCT_PACKAGES += \
         power.hammerhead
    
    +# SuperSU
    +#PRODUCT_PACKAGES += \
    +#    su \
    +#    daemonsu \
    +#    supolicy \
    +#    libsupol.so \
    +#    SuperSU
    
  4. 添加相关文件权限。修改 system/core/libcutils/fs_config.c,寻找 “system/xbin/su”,修改:
    -    { 04750, AID_ROOT,      AID_SHELL,     0, "system/xbin/su" },
    +    { 06755, AID_ROOT,      AID_ROOT,     0, "system/xbin/su" },
    +    { 07777, AID_ROOT,      AID_ROOT,     0, "system/xbin/daemonsu" },
    +    { 06755, AID_ROOT,      AID_ROOT,     0, "system/xbin/supolicy" },
    
  5. 在 system/core/rootdir/init.rc 中添加服务:
    service console /system/bin/sh
         class core
         console
         disabled
    -    user shell
    -    group shell log
    +    user root
    +    group root 
         seclabel u:r:shell:s0
    
    service installd /system/bin/installd
         class main
         socket installd stream 600 system system
    
    +# SuperSU
    +service daemonsu /system/xbin/daemonsu --auto-daemon &
    +    class main
    +    oneshot
    +
     service flash_recovery /system/bin/install-recovery.sh
         class main
         oneshot
    
  6. 编译,刷进去。自此 apk 可通过 SuperSU 获得 root 权限!

存在问题

由于对 AOSP 不熟悉,文件放置不太讲究,不能迎合多设备编译的需求。

还有一个小问题,就是点击 SuperSU 进入主界面时会提示有新 SU 可用,可是我已经下载最新版本了。我估计因为这是最小系统,SuperSU 发现有些文件缺失所以做出提示。

此时注意:不可以点击 INSTALL!因为点击 install SuperSU 会把 install-recovery.sh 加到文件系统里,而我本来又在 init.rc 里写过一次启动了,这会导致多次启动 daemonsu,结果是系统起不来(也可能是别的原因,但至少可以确定的是当我没有在 init.rc 配置启动 daemonsu,而是手动更新的时候,此时点击 INSTALL 系统是能正常启动的)。如果用到 SuperSU 提到的那三种办法,估计就不会多次启动了。因为平时也不需要打开 SuperSU,我就不深究下去了,毕竟编译花时间。

版权所有,转载请注明出处:
http://sickworm.com/?p=367

下载 Android source code(AOSP)遇到的一些问题及解决方法

Published / by sickworm / 下载 Android source code(AOSP)遇到的一些问题及解决方法有1条评论

最近在搞 apk 爆破工程,经常需要调试别人的 apk,每次手动修改 apk 的 debuggable 属性比较麻烦,而且要有时候还不成功。所以还是一劳永逸,下载 AOSP ,把 ro.debuggable 打开,编一个 Nexus 5 的镜像给我手机用。关于 apk 调试的参考链接:https://www.0xaa55.com/technews/201602/00000215.html

建议使用清华镜像,免翻墙。教程链接:https://mirrors.tuna.tsinghua.edu.cn/help/AOSP/

下面是我在 windows 下,使用cygwin 下载官方 AOSP 时遇到的问题及解决办法:(在 windows 下载主要是为了方便我做别的事情,AOSP 官网上说 repo 只支持 linux 和 mac OS,cygwin 理论上也是支持的,但要填一些坑)

1. repo init 失败,request time out / 404

原因是没有翻墙。我使用的是 Proxifier + shadowsocks ,可以全局翻墙。 或者用普通的 VPN 也可以。网上方法是修改 repo 内容,增加 ss 翻墙配置的;也有修改镜像 url,改成国内的。我在 mac 上试过,部分链接还是被墙,没有成功。

2. 使用 cygwin 的 python 无法运行,报错 no module named site / no module named sysconfig / no module named fcntl;或者是 repo init 时 Get 完第一个之后没有预兆直接退出

这个问题可能是好几个原因造成的。首先,cygwin 是会继承 windows 的环境变量 PATH,所以 cygwin 可能会直接用你 windows 下配置的 python。这会带来几个问题:

  1. 直接输入 python 的 play ground 不能正常显示了(没研究具体原因)

  2. repo init 时提示 Get xxx.bundle 后直接退出。我跟了一下 repo 的代码,是 repo 构造 git clone 命令不对,其路径是 Windows 的路径,而不是 cygwin 的路径。

  3. 运行 repo init 时提示 no module named fcntl。上 google 查了一下,有回答说 Windows 没有 fcntl 这个 python 库。这个回答让我放弃了直接用 windows shell 运行 repo 的想法。(最后发现是存在的,不然 cygwin 也没办法运行 fcntl,因为 cygwin 不是 linux 虚拟机,本质也是 windows 的东西。因为网上说 Windows 没有 fcntl 放弃 windows shell,而尝试 cygwin 运行 repo,也是一个挺蠢的想法)

所以需要切换到 cygwin 的 python 。安装方法可以直接运行 cygwin 的 setup,搜索 python 下载。或使用 apt-cyg (需另外安装,网上有教程)执行 “`apt-cyg install python““。安装完成后还需要把 cygwin 的 $PATH 变量修改一下,把 windows 下的 python 路径剔除掉(我这里是 /cygdriver/d/Python27),否则还是会优先使用 Windows 下的 python。修改方法直接在 .bashrc 或 .bash_profile 下改就可以了。切换过来后,后还可能出现问题:

  1. 运行 python 报错 no module named site / no module named sysconfig

原因是 python 包路径错了,你可以输入 “import sys(回车)print sys.path “看一下。我这里就是莫名其妙多了当前目录的路径前缀。

解决办法是为cygwin 设置正确的路径,并写入环境变量 PYTHONPATH 中。我写的是/lib/python27.zip:/lib/python2.7:/lib/python2.7/plat-cygwin:/lib/python2.7/lib-tk:/lib/python2.7/lib-old:/lib/python2.7/lib-dynload

下面是我在 mac 下编译遇到的问题及解决办法:

首先官网上的环境准备要先做好,参考下面链接的 Setting up a Mac OS build environment 章节。防止意外,里面提到的 gmake 降级我都做了。
https://source.android.com/source/initializing

1. build/core/combo/mac_version.mk: Can not find SDK 10.6 at XXX

写这篇文章时 SDK 已经去到 10.12 了,而打开build/core/combo/mac_version.mk 一看,上面写着 supported versions 只支持 10.6 10.7 10.8 10.9。我直接在 supported version 上加了 10.12。结果遇到第二个问题。

2. desperate method XXXX

具体方法名字我忘了,说是 10.12 这个方法已经废弃了。那没办法,搜了一下 SDK 可以从网上下载。下载链接https://github.com/phracker/MacOSX-SDKs/releases

参考文章,教你如何放置 SDK 到正确路径:
http://www.jianshu.com/p/1513fc9e1a74

我看既然是找不到 10.6了,那就直接下 10.6 吧!结果出了第三个问题。

3. no member named llrintl / no member named llroundl

编译器说只有 lrintl 没有 llrintl。我跑去 MacOS SDK 里面看,有 llrintl,但是被宏控制着,因为其不是 C90 标准,需要加 -srd=c99 才可以。但要我找到调用编译的位置实在太麻烦了。

继续 google,有人说 10.11 10.9 都成功了,那我下一个 10.9放进去吧。结果还是提示找不到 10.6。

说好的 supported versions 呢?!我生气的吧 supported versions 中的 10.6 10.7 10.8 都删掉了,10.6 的 SDK 目录也删了,只留了一个 10.9。成功!

4. 切换分支时遇到:error.GitError: manifests rev-list (‘^HEAD’, ‘XXXXX’, ‘–‘): fatal: bad revision ‘^HEAD’

原因可能有好几个,我用了网上的方法都没有凑效。这个错误在我这里是 .git 的 HEAD 值丢失了,至于为什么我也不知道。这条语句的意思是:

在 manifests 这个 git 项目中执行 git rev-list ^HEAD XXXXX — 这个命令时,报错 fatal: bad revision ‘^HEAD’,即错误的版本 HEAD,意思是 HEAD 对应的 git 版本不正确。其中 manifests 这个工程在 .repo/manifests 中。 HEAD 对应的 git 版本存储在 .repo/manifests/.git/HEAD 中,这个 HEAD 文件的值为 ref: refs/heads/default。然后发现并没有 .repo/manifests/.git/heads/default 这个文件。解决办法:在其他目录重新 repo init 一次,把这个文件拷过来即可。

奇怪的是,我之前按照 http://blog.leanote.com/post/gyhlqq@gmail.com/Android-repo-sync-issue-fatal-bad-revision-HEAD-%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88 将整个 repo init 相关的文件都覆盖过去了,这个文件应该也复制过去才对,结果没有。

嗯。。我傻逼了,cp 命令的 src 为目录时,不是拷贝目录,而是把目录下的所有文件拷贝过去。还是推荐上面链接的做法,因为不止这一处会出问题,直接整个覆盖是最吼的。

版权所有,转载请注明出处:

http://sickworm.com/?p=346

Android Studio让module library application并存的尝试

Published / by sickworm / Android Studio让module library application并存的尝试有4条评论

在做UAF的时候,我产生了一个需求:我希望我可以把demoUAF ClientUAF ASM分别打包成3个apk,又可以打包成1个apk。当分别打包的时候,UAF Client/UAF ASM是application;统一打包的时候,UAF Client/UAF ASM是library。我开始进行尝试。

方案1: 通过apply library 和 application plugin进行配置

初步想法

我希望在debug的时候,UAF Client/UAF ASM的build.gradle apply plugin: 'com.android.library',release的时候apply plugin: 'com.android.application'。我找到识别debug和release的方法:

var debug = gradle.getStartParameter().getTaskRequests().toString().contains("Debug")
if (debug) {
    apply plugin: 'com.android.library'
} else {
    apply plugin: 'com.android.application'
}

因为我需要在Generate Signed APK中可以选择UAF Client导出apk,所以需要默认是application。(gradle进行sync的时候会进行一次配置,此时debug变量恒为false)

因为library module无可以配置applicationId,所以还需要:

android {
    defaultConfig {
        if (!debug) {
            applicationId "com.*****"
        }
        // ......
    }
}

然后在demo中加入依赖:

debugCompile project(':asm')
debugCompile project(':client')

存在问题

如此配置导致的问题是gradle sync now失败。报错是“demo无法依赖一个application的module”。但不sync直接运行demo和Generate Signed APK都是可以的。一开始我以为是我debug判断条件有问题,使用println打印信息发现没有输出。

后来了解到gradle sync会遍历一遍gradle文件进行配置,再执行常规编译。在遍历过程中并没有**Debug这样的task进行判断,所以此时UAF Client/ASM是当作application来处理的。

初步想法改进

那为了可以sync成功,我只能把默认改为library了。

var debug = gradle.getStartParameter().getTaskRequests().toString().contains("Debug")
if (!debug) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

这样一来,我就无法使用Generate Signed APK导出UAF Client/UAF ASM了。但同时我发现了一个有趣的现象:在这个配置之下,我导出demo-release.apk的同时,UAF Client和UAF ASM的release.apk也一并导出了。我猜测是配置过程由于我判断条件的干扰导致的。我试着导出demo-debug.apk,UAF Client和UAF ASM还是导出release.apk,但大小和原来不一样了(原本debug版本是带日志的,会大一点)。生成物是正确的,但名字不对。

然后我把混合/独立的判断条件从debug/release改为flavor控制之后,出现了更多的问题。

结论

不可行。

方案2:新建一个module,引用原library/复用原library代码

方案2一听就是靠谱的。通过新建一个module,引用原library module,专门用于导出apk;或通过配置,复用library module的main文件夹:

android {
    sourceSets {
        main.setRoot("../asm/src/main")
    }
}

结论

可行。

思考

为什么我会没想到简单的方案2,而是在方案1中纠结良久,不可自拔呢?因为我不久之前在某个网站(貌似是简书)上看过一篇文章,它最后说明了如何调试多个apk,就是debug的时候把application的module改为library module,release的时候再独立打包。我只留了个印象,没有收藏这篇文章。而到了用到这个的时候我找不到原文章了,但我内心会一直认为该方案可行,且解决方法优雅。

我再想了想,其实合并多个apk对调试并没有什么优势,这样的编译时间反而更长,只让修改部分的apk重新安装还更快速。。

——————————

我再想了想,那篇文章好像讲的是多个独立模块调试时,可以拆开apk独立运行,不用一点修改就要重新打包整个工程,以提高速度。。不过有了 instant run 这个技巧也不是特别有用了。

版权所有,转载请注明出处:
http://sickworm.com/?p=313

Android中Activity/Service获取调用者的信息(FIDO UAF Client获取调用者的信息)

Published / by sickworm / Leave a Comment

实现UAF协议的时候,Client需要获取调用者的信息(获得其APK的签名)。用中文查了半天没查到获取Activity的方法,用英文一下就搜出来了(主要还是看英文累脑子)

Activity:

getCallingActivity()
getCallingPackage()

注意:
只有调用者使用的是startActivityForResult(),且Intent不设置NEW_TASK时才可以获取,调用startActivity()得到的是null。

Service:

Binder.getCallingUid()
Binder.getCallingPid()

注意:
当AIDL使用的是oneway(异步)声明时,Binder.getCallingPid()返回的是0 。

获取到Uid之后,使用getPackageManager().getPackagesForUid(uid)获取到对应的包名。如果多个apk使用了shareUserId的话,返回值将会是多个包,这时候就没办法知道具体是哪个package调用的了。不过使用shareUserId的前提是使用相同的签名文件签名,而UAF要求是得到调用者apk签名的hash,这样的话哪个package调用结果都一样了。

版权所有,转载请注明出处:
http://sickworm.com/?p=270

Android/Java 混淆中使用-assumenosideeffects删除日志代码遇到的问题

Published / by sickworm / Android/Java 混淆中使用-assumenosideeffects删除日志代码遇到的问题有1条评论

今天发包给客户,发现混淆后的库时序有点问题。再三调试,发现锁失效了。wait()没有任何阻塞就跳过了。

ok,90%情况就是在哪里触发了notify/notifyAll咯。但找了很久,notify确实没有被调用。我就纳闷了。

最后我把我的库反编译出来看,发现我的锁的wait()语句被删了!源代码:EsLock.java

public void lock()
{
    synchronized (this) {
        setLocked(true);
        try {
            Log.e("wtf", "" + 1);
            wait();
            Log.e("wtf", "" + 2);
        } catch (Exception e) {
            e.printStackTrace();
            LogUtil.w(TAG, e.getLocalizedMessage());
        }
        setLocked(false);
    }
}

混淆后代码:
https://i0.wp.com/sickworm.com/wp-content/uploads/2016/11/tmp6d1fa6b6.png?w=960

我翻了一下我CI上的库记录,发现前两个月的库是没问题的,看来是中间某段时间修改混淆脚本出了问题。

一番定位,找到了元凶:

-assumenosideeffects class com.excelsecu.driver.util.LogUtil {
    public *;
}

我使用了assumenosideeffects,并尝试将所有com.excelsecu.driver.util.LogUtil的调用删除。官方有关assumenosideeffects的介绍:http://proguard.sourceforge.net/manual/usage.html

assumenosideeffects需要你自己保证你所选择的类的方法没有边界效应(简单来说就是删掉也不会影响程序运行),然后proguard会帮你删掉这些方法的调用。典型例子就是打包时删掉日志输出。官方例子:http://proguard.sourceforge.net/manual/examples.html#logging

需要注意的是:他只会删除这个方法的调用,但是你如何构建你的日志内容(表现形式为StringBuilder)仍然会保留下来。你无法通过这个方法完全删掉你日志的痕迹,以用于保护代码。为什么这样做?因为如果有个傻子图方便直接在log参数里面调用了有边界效应的方法(也就是流程中必不可缺的方法),那你删掉就要出事了。

回到正题:官方给出的示例其实是没有这样的用法,只有填写特定方法的用法。但是这个标签也是支持通配符的,官方对其定义是“-assumenosideeffects class_specification”,class_specification描述了你可以如何描述这个class中的方法。和-keepclass是一样的。这个用法我是在http://stackoverflow.com/questions/6408574/how-to-use-assumenosideeffects-class-android-util-log-in-my-app最下面看到的。

我用回官方的写法:

-assumenosideeffects class com.excelsecu.driver.util.LogUtil {
    public static void v(...);
    public static void i(...);
    public static void w(...);
    public static void d(...);
    public static void e(...);
}

问题没有出现。

所以问题就在于:使用了通配符“public *”之后,proguard把LogUtil之外的方法删了,例如我的EsLock.java中的wait()的调用。(因为这个调用没有返回值,proguard认为是没有边界效应的)

综合来说,我觉得依然是个bug,因为无论如何它不应该把LogUtil之外的方法也删掉。我在https://sourceforge.net/p/proguard/bugs/629/上提交了bug(语法错误好多。。),暂时没有回复。


提交bug后第二天就收到了回复。项目人员给出了相关解释,大概结论就是:这不是bug,proguard是设计成这个样子的。

项目人员提供的相关内容:

http://proguard.sourceforge.net/中:Troubleshooting > “Note: the configuration specifies that none of the methods of class ‘…’ have any side effects”。

简单解释一下:
proguard的混淆是需要往上寻找父类的方法的,所以通配符*也会包括父类的方法。而所有的类都继承与Object,自然Object.wait()和Object.notify()也会在检测列表中。所以当你使用了统配符的时候,这两个方法也是会被影响的。

那么问题来了,为什么不是LogUtil.wait()这样的调用才会被删除,而是EsLock.wait()的方法也会被删除?我猜测proguard采用的是一种展开的方式去处理的,当你配置了LogUtil的所有方法时,他会同时产生一个Object的所有方法的配置。这样处理起来会高效很多。

class specifications是一个统一的定义,-keep等配置也会用到。所以可能很难兼顾所有配置项的使用场景。

官方文档也明确说明了,最好别在assumenosideeffects中使用通配符,这样会影响到wait和notify。

版权所有,转载请注明出处:
http://sickworm.com/?p=259

Android工程使用org.apache.commons.codec(commons-codec)库,运行时提示Base64.encodeBase64URLSafeString“java.lang.NoSuchMethodError”解决方法

Published / by sickworm / Leave a Comment

最近工作是开发FIDO UAF项目。FIDO UAF是一个旨在提供身份验证通用方案,以代替繁杂密码记忆的一个方案,Google,阿里这些大头都是核心成员,感觉是用来未来代替密码的1号方案。可能是定义的太通用了,UAF目前应用面还不广。

UAF还有个兄弟叫U2F,是个更精简的方案。U2F是一个用硬件外设(token)代替密码的方案,有点像u盾。外国已经有相关设备,Google登录已经可以通过U2F设备进行验证。使用很方便:你在电脑插入一个U2F设备(初次需要绑定账户),再打开网页,Google就自动为你登录。腾讯也有做一个叫QKey的,很快就会面市了。U2F实用性比较强。

回到正题,我在开发过程中,同事找到了eBay的UAF实现开源代码。我稍微看了一下,看到他们的Base64编码是使用了Base64.encodeBase64URLSafeString这个方法。我试了一下,和普通的Base64编码不同的是把编码末尾的”=“号去掉了。这样的话Http的Get参数就不会出现问题。虽然UAF要求使用POST发送请求,但我看到大佬都这么做,我就跟着用吧。

这个方法在org.apache.commons.codec(commons-codec)中定义。我也下了这个库,放在我自己的项目中,并替换了原来的Base64实现。而稍后在我进行单元测试的时候出问题了。Android单元测试提示我找不到“Base64.encodeBase64URLSafeString”这个方法。

这就奇怪了,编译期没有报错,运行时报错?我一下子没想明白。我反编译commons-codec库,里面是有这个方法的。我在运行时用反射打印出来,没有这个方法。然后我用Java单元测试试了一下,Java单元测试通过。

那看来是Android运行环境的问题了。我上网找了一下,居然有和我一样问题的人:
java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64

里面写的很清楚,Android的framework引用了一个旧版的commons-codec(而这个旧版本没有这个方法)。这会导致后加载的同一名称的包无效(无法加载并覆盖)。所以我在运行时就找不到这个方法了。

解决方法

没办法。Java的类加载安全机制决定了我们没办法使用后加载的类。我想起在“码农翻身”公众号里有看过相关的文章。我找了一下,节选如下:

我感到前途未卜, 但也不能坐以待毙, 一定得多了解信息。
“大哥, 你叫什么名字” , 我看小个子还算和气。
“我就是大名鼎鼎的文件验证器了, 能管很多事”
“那刚才他为啥还得请示上级呢” , 我用眼神指了一下开车的ClassLoader
文件验证器的声音一下子就压低了:
“你不知道,说来话长, 我们之前出现过事故,有个黑客写了个类java.lang.String, 和我们老板手下有一个干活最卖力的员工名字一模一样,只是这个黑客类里边竟然有格式化硬盘的代码,我们的小兵Classloader 不明就里,就把 这个黑客类给先装载了,也执行了, 最后的结果,唉,很惨的… ”

“那后来怎么办?”
“后来我们老板就定下了规矩:他的骨干员工像String, ArrayList等只能由他自己的心腹去装载, 我听说老板的心腹都是分层级的,像传销一样, 每个都有上线, 最顶层的叫Bootstrap Classloader , 下一次级叫Extension Classloader, 现在开车的这位其实叫App Classloader,位于最底层, 咱这位Classloader 在装载一个类之前,一定要问一问这几位权利极高的大爷,请他们先装载,这几位爷装载不了,才由我们这些小兵来出马。“

其实只要先加载了就没办法再重新加载了。我们普通app环境做不到上述黑客的环境,上面的文章只是给大家加深记忆。

不过如果你的类是你自己用Classloader 加载的话,还是可以重新加载的,相关文章:
JAVA动态重新加载Class机制

有办法。其实你把里面的实现拷出来,换个包名也可以。但是类之间的互相依赖可能会有点多。

但我突然发现,

为什么eBay的代码却用了这个库呢????他们是不是没有实际跑过呢???【黑人问号】

总结

Android工程使用org.apache.commons.codec(commons-codec)库,运行时提示“java.lang.NoSuchMethodError”的原因是:Android内部已经加载过同名的旧类库,导致项目中引用的库无法加载,而旧库的Base64类又没有这个方法。

解决方法是:
1. 换一个库,使用Android自带的Base64方法,并加上Base64.URL_SAFE标记位。(最好是Base64.NO_WARP | Base64.NO_PADDING | Base64.URL_SAFE)
2. 把实现拷出来(依赖过多,不现实)

版权所有,转载请注明出处:
https://sickworm.com/?p=175

linux中运行zipalign/aapt提示:No such file or directory解决办法

Published / by sickworm / Leave a Comment

最近在用Docker+Jenkins做持续集成(CI),中间有个步骤需要调用zipalign对齐jar包,但我运行zipalign的时候却提示:
No such file or directory。

这就奇怪了,找不到这个二进制文件???百思不得其解。。此时我在Mac和Windows上都是可以运行对应平台的zipalign。

首先,
我怀疑是我下的adt有问题。于是我下了3个版本的adt,都报这个错,排除。

然后,
我怀疑我的Docker虚拟机有问题,我把zipalign扔上阿里云运行,报同样的错误。

接着,
我猜测可能zipalign依赖同个文件夹里面的其他运行文件或so库。于是我整个adt拷过去,问题依然存在。

再然后,
求助谷歌,翻到若干的解决方案:
Add the tools to your PATH, or use the full path to zipalign.
copy the Zipalign file from sdk/build-tools/android-4.4W folder to sdk/tools/
以上皆无法解决。

后来我搜索“Linux no such file or directory原因” 找到:
Linux执行可执行文件提示No such file or directory的解决方法
原来是库不匹配的原因。
再搜索“Linux zipalign no such file or directory” 找到:
sudo apt-get install libc6:i386 libstdc++6:i386 zlib1g:i386

先apt-get update,再安装上面的库,提示找不到。(后来了解到要用dpkg拉i386的软件仓库才可以下载:i386的库。其实64位软件库也有32位的库)
我试着碰运气,直接安装libc++6,173M。(依赖大量32位库。后期实验,只需要安装lib32stdc++6和libc6-i386即可)
安装完成后,提示另一个错误:
error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
继续google,找到:
sudo apt-get install lib32z1
安装,解决。

所以zipalign:No such file or directory的原因是找不到匹配的32位库。
提示这个错误可能是二进制文件错误处理信息不够完善。

版权所有,转载请注明出处:
http://sickworm.com/?p=197

二维码扫描开源库ZXing定制化

Published / by sickworm / Leave a Comment

最近在用ZXing这个开源库做二维码的扫描模块,开发过程的一些代码修改和裁剪的经验和大家分享一下。

建议:

如果需要集成到自己的app上,而不是做一个demo,不推荐用ZXing的Android外围开发模块,只用核心的core目录的代码就好了。android和android-core的代码设计的不好,扩展性太差了(我在后期开发新需求的时候改修改了很多CameraManager的逻辑)。只使用core目录的集成方法很简单,参考:

https://github.com/zxing/zxing/blob/master/android/src/com/google/zxing/client/android/DecodeHandler.java

中的decode函数,把摄像头数据转换成二值化图像,然后传入MultiFormatReader解码。

 

以下是正文:

我的代码库:(基于官方3.2.0)

https://github.com/SickWorm/ZXingDialog

代码没有在github维护,所以没有log。但是所有修改的地方我都加上了“@ch”的注释,以方便定位

官方源码:

https://github.com/zxing/zxing

 

实现功能:

1、功能裁剪(只保留QRCode二维码扫描功能,去掉条形码等其他码扫描功能)

2、移除资源依赖,提供Dialog形式的扫码功能

3、API兼容(源码只兼容4.0以上,现兼容至2.1)

4、转换为竖屏(源码为横屏)

5、扫码速度优化(主要分三点,现只完成了一点)

6、设备兼容(针对低分辨率设备)

本文还会提到:

7、自定义界面

8、优化调试方法

 

1、建立工程

ZXing源码并没有提供一个完整的实例工程给我们使用,构建一个工程我们需要源码下的三个文件夹的文件:

core/

android-core/

android/

大概步骤如下:

1、创建一个新工程

2、把android目录下的所有文件覆盖到新工程(内含有资源文件和AndroidManifest.xml等构建app所需的文件)

3、把android-core所有Java文件拷入到src目录下(注意!android-core中的src文件夹需要进行一些改动,原来路径是android-coresrcmainjavacomgooglezxingclientandroidcamera,我们要把中间的mainjava两层文件夹去掉,不然在Eclipse中无法识别包路径)

4、把core目录下的所有Java文件拷入到src目录下(注意!和步骤3一样需要去掉mainjava两层文件夹)。这样ZXing已经可以运行了,我的src目录是这样的:

可以直接运行,效果还不错。如果你遇到一些错误,有可能是编译的JDK版本低于1.7导致的。源码里使用了ArrayList<>这样的写法,1.7以前是不支持的。你可以选择修改源码或者提高编译JDK版本。

但你可能不满足于这个界面,扫描框太大了,而且是横屏全屏的,还要求API 15(Android 4.0.3)。下面我们会对这些需求进行修改。

2、代码优化

1、功能裁剪(只保留QRCode二维码扫描功能,去掉条形码等其他码扫描功能)

我的目标是只保留二维码识别,不需要其他多余的功能。这一部分的步骤我不打算详细说明,因为我已经不记得了。。大家可以直接看我的代码的结果。

可以直接删掉的是:

com.google.zxing.aztec.**  aztec格式的二维码

com.google.zxing.client.android.book.*  Google 图书相关的功能

com.google.zxing.client.android.clickboard.*  不清楚,复制黏贴?

com.google.zxing.client.android.encode.*  用于生成各种码

com.google.zxing.client.android.history.*  保存扫码记录

com.google.zxing.client.android.result.**  扫码应用功能相关的功能性代码

com.google.zxing.client.android.share.*  分享功能

com.google.zxing.client.android.wifi.*  WiFi相关,不清楚具体用途

com.google.zxing.datamatrix.**  datamatrix格式二维码

com.google.zxing.maxicode.**  maxicode格式二维码

com.google.zxing.multi.**  貌似是用于多格式支持的?我没有用到这个包,如果有了解的麻烦告知

com.google.zxing.oned.**  one dimension一维码,也就是条形码(你去百度搜oned会发现奇怪的东西。。)

com.google.zxing.pdf417.**  PDF417格式条形码

需要修改的是:

com.google.zxing.client.android.CaptureActivity:去掉其他功能的相关代码,只保留核心功能,即扫码功能。界面为一个FrameLayout里面包含一个SurfaceView。代码移除就不详细说了,直接看上传的代码吧,这个文件我参考了http://www.cnblogs.com/keyindex/archive/2011/06/08/2074900.html这个链接里的CaptureActivity的修改。

com.google.zxing.MultiFormatReader:这个是指定支持解码的格式,需要把除QR_CODE以外的格式全部去掉,否则会因为删掉了解码包而报错。具体也请看上传的代码。

com.google.zxing.client.result.ProductResultParser:parse函数中,同上。

com.google.zxing.client.android.DecodeThread:构造器中,同上。

另外:

com.google.zxing.client.result 我没有删减这个包的代码,应该也是能优化的

2、移除资源依赖,提供Dialog形式的扫码功能

经过了第1步的精简,其实只剩下了2个地方需要修改:

1.扫描界面

2.扫描成功时播放的beep声音文件

 

1:去除了其余功能后,对于核心功能我们只需要一个SurfaceView和一个画界面的View就可以了。代码如下:

/** * use Java code to build layout instead of xml file * @ch */
private void buildLayout() {
    requestWindowFeature(Window.FEATURE_NO_TITLE);
    FrameLayout layout = new FrameLayout(this); 
    LayoutParams params = new LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT); 
    layout.setLayoutParams(params); 
    surfaceView = new SurfaceView(this); 
    surfaceView.setLayoutParams(params); 
    layout.addView(surfaceView); 
    viewfinderView = new ViewfinderView(this, null); 
    layout.addView(viewfinderView); 
    setContentView(layout); 
}

ViewfinderView是ZXing自带的View,如果要修改界面,直接修改它就可以了,我们第7点会提到。

2:由于我最终的目的是能打包成jar包,所以beep文件不能放在res里,而是放在assets里。

//待补充

 

3、API兼容(源码只兼容4.0以上,现兼容至2.1)

这部分修改在源码中标记为//@ch api compatible。

CaptureActivity.java:

if (VERSION.SDK_INT < 11) {
    //surfaceview will push buffer automatically
    surfaceHolder.setType(SurfaceHolder.SURFACE_TYPE_PUSH_BUFFERS); } 
    //API 11之前需要手动设置,否则会无法显示。API11之后为默认设置。
    CameraConfigurationManager.java: //@ch api compatible
    if (VERSION.SDK_INT < 13) { 
        theScreenResolution.x = display.getWidth(); 
        theScreenResolution.y = display.getHeight(); } else { display.getSize(theScreenResolution); 
    } 
    //getSize是API 13之后的新API,之前需要用getWidth和getHeight。

AutoFocusManager.java:

if (VERSION.SDK_INT > 11) { 
    newTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR); 
} else { 
    newTask.execute(); 
} 

// 源码中这里设置了多线程的模式,THREAD_POOL_EXECUTOR表示这个task最多只有5个线程同时运行,超过5个的就要等待。在低于API 11的版本中,此为默认选项。其实这里只有单线程,所以随便执行吧。

OpenCameraInterface.java:

if (VERSION.SDK_INT < 9) { 
    return openWithLowApi(); 
} ...... /** * for lower than API 9 * @ch api compatible */
    
public static Camera openWithLowApi() { 
    //If the device does not have a back-facing camera, this returns null
    Camera camera = Camera.open(); 
    return camera; 
} 
//源码的打开摄像头是能区分前后摄像头的,然而API 9之前并没有前置摄像头这个概念,所以做了一下处理

就几个地方,不过也找了我个把小时了。

 

4、转换为竖屏(源码为横屏)

ZXing默认是横屏,但是我们一般的APP都会做成竖屏,如果扫码的时候强制切换成横屏那样体验就不好了。在修改ZXing的竖屏的时候,我按照的是一般APP的竖屏设置方法,结果发现没有源码的效果好,需要把码放到很小才能完成。后面在调试过程中发现扫码解析的区域和屏幕画出来的区域不一样,才知道这部分的修改出了问题。然后我搜索找到一篇前辈的文章,参考了一下发现没有改完全。附上文件链接:

http://blog.csdn.net/aaawqqq/article/details/24804939

其中第五点我没有修改,文章中的源码可能比较旧,并不适合替换。第5点不替换替换是没有问题的。

此外还有一点需要修改的是:

CameraManager.java:

//@ch change 240 to 120 for 320x240 machine
private static final int MIN_FRAME_WIDTH = 120; private static final int MIN_FRAME_HEIGHT = 120; //@ch change to vertical
private static final int MAX_FRAME_HEIGHT = (int) 1080; 
private static final int MAX_FRAME_WIDTH = (int) 1080; 
//此处为扫描框最大边界和最小边界的界定。但因为我最后做成了正方形,所以这里数值是一样的。如果为矩形,需要把两个值交换一下。 //设置最小值是为了保证解码的成功率,毕竟分辨率太小就没法识别了。最大值是为了保证解码速度。其实最大值应该通过插值来重新构图,不然框的大小不一致体验就不好了。不过这样的分辨率起码是2K屏以上了,所以最大值设定不会有什么影响

5、扫码速度优化(主要分三点,现只完成了一点)

1.二值化算法优化。ZXing一共提供了两种二值化算法,一种是HybridBinarizer,另一种是GlobalHistogramBinarizer,默认使用的是HybridBinarizer。我搜集资料的时候发现,HybridBinarizer算法用了更高级的算法,运算要求更高,而总体来讲GlobalHistogramBinarizer识别率要更高。在我的实际测试中(我用的Nexus5,Android 5.0.1),GlobalHistogramBinarizer效果确实是要好不少。

这里的修改很简单,换一个类就可以了:
DecodeHandler.java:

private void decode(byte[] data, int width, int height) {
    ...... 
    //@ch you can use HybridBinarizer or GlobalHistogramBinarizer 
    //but in most of situations HybridBinarizer is shit
    BinaryBitmap bitmap = new BinaryBitmap(new GlobalHistogramBinarizer(source)); 
    ...... 
}

2.对焦优化。ZXing中的对焦功能在AutoFocusManager.java中,功能非常简单,设置自动对焦并2秒对焦一次。但自动对焦可能会带来一个问题,如下图:

jingshen

(图片源自网络)

把二维码当作图中的那朵花,自动对焦则容易使摄像头对焦到背景(图中女性)中去。我在测试中使用三星S4的自动对焦经常对不了二维码。这里我们可以使用区域对焦的方法(对焦的区域即是扫描框的区域):

//定点对焦的代码 
private void pointFocus(int x, int y) {
    if (cameraParameters.getMaxNumMeteringAreas() > 0) { 
        List<Camera.Area> areas = new ArrayList<Camera.Area>(); 
        Rect area = new Rect(x - 100, y - 100, x + 100, y + 100); 
        areas.add(new Camera.Area(area, 600));
        cameraParameters.setMeteringAreas(areas); 
    } 
    mCamera.cancelAutoFocus(); 
    cameraParameters.setFocusMode(Parameters.FOCUS_MODE_AUTO); 
    mCamera.setParameters(cameraParameters); 
    mCamera.autoFocus(autoFocusCallBack); 
}

区域对焦需要API 14以上。关于对焦暂时没有更多的想法,但我觉得确实是有优化的余地的。

3.算法优化。算法主要分两部分,第一部分是二值化,第二部分是提取码值。第二部分又分为1.寻找定位符,2.寻找校正符,3.转换矩阵。在测试过程中,影响识别的最大问题就是找不到定位符,即二维码左上角、右上角、左下角的三个黑白相间的矩形点。比较大的原因可能是二值化部分的问题。这一部分暂时也还没有深入。

6、设备兼容(针对低分辨率设备)

CameraManager.java中有设置最小扫描框大小的参数MIN_FRAME_WIDTH和MIN_FRAME_HEIGHT。默认是320×240。这对于屏幕分辨率为320×240的设备,扫描框就会变成全屏的。这里我改成了120×120,实际在屏幕分辨率为320×240的设备上也可以扫到二维码。

 

7、自定义界面

界面写在ViewFinderView.java中。扫描框大小由CameraManager决定。修改的时候需要注意和CameraManager的配置关联起来,否则会出现扫描框和实际解码的区域不一致。(ZXing的android外围模块代码默认使用的是全屏,如果你想改为非全屏(比如加一个action bar),肯定会造成扫描框区域和实际解码的区域不一致的问题。这也是文首建议只使用core模块的原因)

 

8、优化调试方法

为了应对7可能带来的问题,我自己做了一个调试的方法,以保证扫描框内容和实际解码内容一致。首先在CaptureActivity.java初始化cameraManager的地方,把

cameraManager = new CameraManager(getApplication())

改为cameraManager = new CameraManager(this)

这样做的目的是:传入了activity给CameraManager,使得后面在CameraManager中的调试内容可以直接输出在activity上(dialog也一样,改为getContext()即可)。但注意这样会带来Activity生命周期问题和因为互相引用导致内存泄漏的问题。所以只能在调试阶段修改成上面的写法。

然后在CameraManager.buildLumianceSource中加入:

if (context instanceof Activity) {
    final Bitmap bitmap = Bitmap.createBitmap(BitmapUtil.createBitmapfromYUV420(data, width, height), rect.left, rect.top, rect.width(), rect.height()); 
    CaptureActivity activity = ((CaptureActivity) context); 
    final ViewfinderView view = activity.getViewfinderView(); 
    activity.runOnUiThread(new Runnable() { 
        @Override 
        public void run() { 
            view.drawResultBitmap(bitmap); 
        } 
    }); 
}

这样,屏幕上的扫描框中就会显示出实际解码的图像,你可以通过比对预览图像查看是否对齐。

记得调试完改回来getApplication()

 

版权所有,转载请注明出处:

http://sickworm.com/?p=41