Android:加载PDF几种方法汇总对比

在安卓项目中,加载PDF文件,是一个比较常见的需求。又分为两大类,

1.加载网络PDF

2.加载一个本地静态PDF。


查阅资料,纵观网上在安卓中打开PDF的各种方式,大致可以分为以下几类,

1.直接使用第三方软件打开(包括浏览器打开和第三方软件打开)

如果是在app内部加载PDF文件,虽然安卓原生API对于PDF的支持又不是太好,但是各种第三方专门的阅读或者办公软件支持的是很不错的,可以通过Intent配置data和type实现。

其中,在实际需求中又会分为加载本地PDF和网络PDF的情况。

使用浏览器打开PDF:(APP外部打开,适用于加载网络PDF)

使用手机上已安装的可以打开PDF的第三方软件来打开PDF:(APP外部打开,适用于加载本地PDF)

(使用这种方式缺点是:手机上如果一个可以打开PDF的软件,那么就尴尬了~)


2.连接Google服务器解析

安卓的WebView不支持PDF解析,因此通过连接Google的一个服务器转换成功后返回给WebView显示。但是,但是,但是呢,大家都懂的,天朝和Google之间有一道高高的墙。方法还是贴出来,作为国际化APP的一种方案。


3.用第三方库加载

Github上有一个Java开源项目 https://github.com/barteksc/AndroidPdfViewer ,
这个库的大致原理,是内置了一个PDF解析器,以流的方式将网络PDF从网上Down下来,然后再以流的方式将其还原成PDF展示出来(具体细节没关注)。亲测中,这个库每次进入webview页面都会解析加载一遍PDF,如果PDF过大,费时无缓存不说,最致命的问题乃是,

APK包体积会瞬间增大15M左右,

具体原因不明,估计应该是内置PDF解析器的问题。于是,此方法被我抛弃了。


4.使用Moliza开源的Pdf.js

这个JS类库也是很强大的,配合原生的WebView使用,支持预览,缩放,翻页的功能,实现效果和WKWebView没差。同样也有体积问题,全部放到本地apk的话包大小差不多会增加5M左右。但相比上一种方式还是轻量一些:
http://www.jb51.net/article/136364.htm


5.使用安卓自带的PdfRenderer类加载

如果要求支持的功能不是很多,用安卓提供的PdfRender就可以满足需求了。PdfRender加载多页的话可以配合ViewPager或者RecyclerView使用。需要注意的是使用PdfRender需要先将PDF文件下载到本地,是线程不安全的,并且API>=21才能使用。因为这种方式是将PDF下载到本地,于是就产生了新问题:占内存。如果是静态的PDF文件不大还好,但是如果是频繁加载网络PDF的需求,那就头疼了,这种方式需要做好定时清理删除PDF的工作,否则,GG。

这里提供的示例是阿里巴巴Android开发手册,放到assets目录下.

PdfRender的大致调用方式是:

  • 初始化PdfRender,将PDF文件转换为ParcelFileDescriptor作为入参
  • 通过getPageCount()获得Pdf的总页数
  • 循环遍历,通过openPage()获得一个封装了当前页Pdf参数的内部类Page
  • 创建一个Bitmap对象,,用上步获取的Page加载,相当于把当前Pdf页的内容渲染到了Bitmap上
  • 对Bitmap进行你想要的操作,每次循环结束后关闭当前Page。

大部分都是常规操作,但要注意两点:

1. 每次循环创建的Page对象在使用完毕后必须调用close()。否则其内部的openPage()判断会抛异常;

2.Bitmap占用内存较大,如果用ViewPager加载一定要重写Adapter中的destroyItem(),及时的将需要销毁的视图从父容器中移除,否则快速滑动几页后会OOM。

参考链接


android:加载PDF几种方法汇总对比

如何让Android Studio/IntelliJ IDEA不对自定义的NULL检查方法发出警告

在平时的开发过程中,我们一般会自定义函数对变量是否为 null 进行检查,当检查函数返回成功的时候,对象一定不是 null

但是,这个自定义的函数,对于 Android Studio/IntelliJ IDEA 来说,是无法感知到的,导致 Android Studio/IntelliJ IDEA 会发出警告,没有对变量是否为 null 进行检查。

出现上述问题的例子如下:

那么,有没有办法告知 Android Studio/IntelliJ IDEA ,我们已经对 null 进行过检查了呢?

网上搜索许久,尝试过 @CheckForNull / @EnsuresNonNullIf 注解,都不能解决问题。

最终发现使用 jetbrains@Contract 注解能解决此问题。

上述的例子增加以下注解,明确告知编译器,如果参数是 null 函数一定返回 false,就可以阻止编译器发出警告了。

如下:

参考链接


Android各大市场更改APP名称

公司上架了一款App,因为产品运营需要去修改App名称,在iOS应用市场提交新版本的时候可以改App名称。那么Android 各大市场如何更改APP名称呢?

目前上架的Android 应用市场有:360手机助手、腾讯应用宝、百度手机助手、阿里应用分发市场(豌豆荚)、安智市场、小米应用商店、华为应用市场、OPPO商店、魅族应用商店、vivo应用市场、搜狗手机助手等平台。

每家Android应用市场的规则都不同,小编整理了Android 各大市场更改APP名称的规则。

1、 百度 : 百度平台的最简单。直接更新app的版本即可(应用名称是系统从您提交的应用中解析的,如需修改请联系贵司技术修改apk包内信息。)

百度如何修改app名称
百度如何修改app名称

2、应用宝: 用上线后,开发者可通过工单系统提交应用名称修改需求 (入口1:如图点击“名称更改指引”即可直接跳转到修改应用名称的工单系统;入口2:管理中心-->点击需要修改名称的应用-->基础服务-->工单系统-->应用宝商务类-->移动应用名称修改-->填单提交)。修改应用名称需要提供软件著作权; 若暂无软著,可提供此款应用在其他外市场,改过名字后的前后台上线管理截图(其他证明文件均不接受);

腾讯开放平台应用改名
腾讯开放平台应用改名

重要提示:根据平台规则,应用上线后,应用名称最多可支持修改2次,超过修改次数将不再受理,请谨慎确定好需要修改的应用名称后,再提交工单申请。

腾讯移动应用名称修改
腾讯移动应用名称修改

3、华为: 在开发者后台在该应用下点击上架或者升级,上传更名后的APK包,并在应用信息处更改应用名称,如应用分类涉及软著要求,请在“版本信息”的“应用版权证书或代理证书”处更新应用软著及免责函,提交应用审核。

华为应用商店应用改名
华为应用商店应用改名

4、360移动开放平台和百度移动开放平台是一样的,直接更新app的版本即可。

5、 vivo开放平台:

1)应用类APP需要修改名称: 直接在后台编辑更新,保证apk包内和在后台填写的名称一致即可;若名称相差较大,请在版权证明栏补充软著;游戏类APP(网游/单机)需要修改名称:需联系对接商务处理。

2)若需要更改应用包名,请联系贵司技术人员;更改之后再在平台创建应用提交新包名应用,旧包名应用需申请下架(登录平台--管理中心--点击您的应用--“下架申请”即可)。

6、 OPPO开放平台:也是上传后将自动解析包名。

7、魅族开放平台:也是上传后将自动解析包名。

8、小米市场: 应用名称修改需于应用包内及应用信息一同更改。应用包内名称更改还请贵司技术开发人员自行更改。(可以试一下直接上传后将自动解析包名。)

9、豌豆荚(阿里云应用分发平台):也是上传后将自动解析包名。

参考链接


Android 各大市场更改APP名称

编译NanoPi R5S Android 12 (RK3568)

最近,入手了一部 NanoPi R5S ,官方是提供了 Anroid 12 的系统镜像,但是却没有给出相应的源代码2023年10月12日,NanoPi 官方已经给出了Android 12的源代码,整个共享目录大约130GB左右,建议直接使用官方源代码进行编译)。尝试用官方提供的 Anroid 11 编译,结果编译出的系统镜像无法正常运行。

凑巧看到 研华科技 放出了 RSB-4810 开发板的 Anroid 12 编译指南,两者的配置差不多,试了一下,竟然可以正常运行!!

系统要求,内存不低于 32GB,否则编译过程中可能会由于内存不足,造成编译失败。

研华科技 官方文档是通过 docker 利用 ubuntu 18.04 进行编译的,如下:

1. 配置 docker 运行环境

2. 下载源代码并进行编译

3. 下载并解压缩编译工具( prebuilts.tar.gz 密码: 1234)

4. 编译代码

5. 核对编译后的文件

编译完成后的产物在 rockdev/Image-rsb4810_s/ 目录下,具体的文件列表如下:

5. 刷机

按照正常的流程刷机,整个流程走起来会比较繁琐,此处给相对简单的做法。

    1. NanoPi R5S官方WIKI 去下载已经编译好的镜像
    2. 如果是需要SD卡刷机,则直接把下载到的镜像文件写入准备好的数据卡
    3. 用刚刚编译出的文件替换SD卡上的android12目录下的同名文件,注意,只替换同名文件,里面的配置文件不要删除
    4. 插上SD卡,重启即可完成刷机
    5. 如果使用USB刷机,则也可以通过替换文件的方式达到相同的目的

参考链接


Robolectric 4.8.2修改进程名/私有静态变量

Roboletric 4.8.2 修改进程名:

Roboletric 4.8.2 修改私有静态变量:

如果报错:

则修改方式如下:

完整的例子如下:

参考链接


Using PowerMock - robolectric/robolectric Wiki

Android Studio升级ArcticFox后单元测试报错“Test events were not received”

Android Studio升级ArcticFox后单元测试报错“Test events were not received”,如下图:

解决方法:目前最简单的方法就是升级到 Android Studio Chipmunk|2021.2.1 Path 2,然后对项目整体执行一次Clean,删除之前的测试用例并重建。

操作步骤如下图:

1. 清理工程代码,移除缓存

2. 选中出问题的测试用例的编辑配置

3. 移除之前的测试用例,这样可以迫使测试用例重建

4. 再次执行测试用例

参考链接


Android获取当前进程的名称

通过 ActivityManager 获取进程名

缺点:

  1. am.getRunningAppProcesses()需要跨进程通信,效率不高
  2. ActivityManager.getRunningAppProcesses() 有可能调用失败,虽然概率不高但是当用户数量达到一定级别还是有概率失败的
  3. Application.getProcessName() 只能Api28 以上的系统调用

最优解:

参考链接


android 获取当前进程的名称

Collections.singletonList/Collections.emptyList/Collections.emptyMap

最近在研究 Flutter pigeon 例子 的时候,发现如下实例代码:

对其中的 Collections.singletonList(result) 比较感兴趣,研究了一下,发现还是比较有意义的。

Collections.singletonList()

这个方法主要用于只有一个元素的优化,减少内存分配,无需分配额外的内存,可以从SingletonList内部类看得出来,由于只有一个element,因此可以做到内存分配最小化,相比之下ArrayListDEFAULT_CAPACITY=10个。

下面是SingletonList静态类的定义

上面的源码中可以看到,静态类中并没有重新add、delete、set等方法。所以通过Collections.singletonList初始化的List是不能执行上述方法的。

Collections.emptyList()

Collections.emptyList在日常开发中也比较常用,如果一个方法需要返回一个空List,并且后续不用再新增元素进去,我们完全可以直接返回Collections.emptyList()而不是new ArrayList;这样不用每次都去创建一个新对象。

EMPTY_LIST如下

Collections中其他类似方法

参考链接


另一种绕过Android P以上非公开API限制的办法

去年发布的 Android P 上引入了针对非公开 API 的限制,对开发者来说,这绝对是有史以来最重大的变化之一。前天 Google 发布了 Android QBeta 版,越来越多的 API 被加入了黑名单,而且 Google 要求下半年 APP 必须 target 28,这意味着现在的深灰名单也会生效;可以预见,在不久的将来,我们要跟大量的 API 说再见了。

去年我给出了一种绕过Android P对非SDK接口限制的简单方法,经验证,这办法在 Android Q 的 Beta 版上依然能正常使用。虽然这个方法需要进行内存搜索,理论上有可能失败,但实际上它曾在 VirtualXposed 和 太极 中得到了较为广泛的验证,从未收到过由于反射失败而导致问题的反馈。而且据我所知,有若干用户量不少的 APP 在线上使用 FreeReflection 库,想来应该也是没有问题的吧。

不过今天,我打算给出另外一种绕过限制的办法。这个办法目前来说是最优方案,我个人使用了一个多月,不存在任何问题。

上次分析系统是如何施加这个限制 的时候,我们提到了几种方式,最终给出了一种修改 runtime flag 的办法;其中我们提到,系统有一个 fn_caller_is_trusted 条件:如果调用者是系统类,那么就允许被调用。这是显而易见的,毕竟这些私有 API 就是给系统用的,如果系统自己都被拒绝了,这是在玩锤子呢?

也就是说,如果我们能以系统类的身份去反射,那么就能畅通无阻。问题是,我们如何以「系统的身份去反射」呢?一种最常见的办法是,我们自己写一个类,然后通过某种途径把这个类的 ClassLoader 设置为系统的 ClassLoader,再借助这个类去反射其他类。但是这里的「通过某种途径」依然要使用一些黑科技才能实现,与修改 flags / inline hook 无本质区别。

以系统类的身份去反射 有两个意思,1. 直接把我们自己变成系统类;2. 借助系统类去调用反射。我们一个个分析。

「直接把我们自己变成系统类」这个方式有童鞋可能觉得天方夜谭,APP 的类怎么可能成为系统类?但是,一定不要被自己的固有思维给局限,一切皆有可能!我们知道,对APP来说,所谓的系统类就是被 BootstrapClassLoader 加载的类,这个 ClassLoader 并非普通的 DexClassLoader,因此我们无法通过插入 dex path的方式注入类。但是,Android 的 ART 在 Android O 上引入了 JVMTI,JVMTI 提供了将某一个类转换为 BootstrapClassLoader 中的类的方法!具体来说,我们写一个类暴露反射相关的接口,然后通过 JVMTI 提供的 AddToBootstrapClassLoaderSearch将此类加入 BootstrapClassLoader 就实现目的了。不过,JVMTI 要在 release 版本的 APP 上运行依然需要 Hack,所以这种途径与其他的黑科技无本质区别。

第二种方法,「借助系统的类去反射」也就是说,如果系统有一个方法systemMethod,这个systemMethod 去调用反射相反的方法,那么systemMethod毋庸置疑会反射成功。但是,我们从哪去找到这么一个方法给我们用?事实上,我们不仅能找到这样的方法,而且这个方法能帮助我们调用任意的函数,那就是反射本身!可能你已经绕晕了,我解释一下:

  1. 首先,我们通过反射 API 拿到 getDeclaredMethod 方法。getDeclaredMethod 是 public 的,不存在问题;这个通过反射拿到的方法我们称之为元反射方法

  2. 然后,我们通过刚刚反射拿到元反射方法去反射调用 getDeclardMethod。这里我们就实现了以系统身份去反射的目的——反射相关的 API 都是系统类,因此我们的元反射方法也是被系统类加载的方法;所以我们的元反射方法调用的 getDeclardMethod 会被认为是系统调用的,可以反射任意的方法。

伪代码如下:

到这里,我们已经能通过「元反射」的方式去任意获取隐藏方法或者隐藏 Field 了。但是,如果我们所有使用的隐藏方法都要这么干,那还有点小麻烦。在 上文中,我们后来发现,隐藏 API 调用还有「豁免」条件,具体代码如下:

只要 IsExempted 方法返回 true,就算这个方法在黑名单中,依然会被放行然后允许被调用。我们再观察一下IsExempted方法:

继续跟踪传递进来的参数 runtime->GetHiddenApiExemptions() 发现这玩意儿也是 runtime 里面的一个参数,既然如此,我们可以一不做二不休,仿照修改 runtime flag 的方式直接修改 hidden_api_exemptions_ 也能绕过去。但如果我们继续跟踪下去,会有个有趣的发现:这个API 竟然是暴露到 Java 层的,有一个对应的 VMRuntime.setHiddenApiExemptions Java方法;也就是说,只要我们通过 VMRuntime.setHiddenApiExemptions 设置下豁免条件,我们就能愉快滴使用反射了。

再结合上面这个方法,我们只需要通过 「元反射」来反射调用 VMRuntime.setHiddenApiExemptions 就能将我们自己要使用的隐藏 API 全部都豁免掉了。更进一步,如果我们再观察下上面的 IsExempted 方法里面调用的 DoesPrefixMatch,发现这玩意儿在对方法签名进行前缀匹配;童鞋们,我们所有Java方法类的签名都是以 L开头啊!如果我们把直接传个 L进去,所有的隐藏API全部被赦免了!

详细代码在这里:https://github.com/tiann/FreeReflection

理论上讲,这个方案不存在兼容性问题。即使 ROM 删掉了 setHiddenApiExemptions 方法,我们依然可以用「元反射」的方式去反射隐藏API,并且所有的代码加起来不超过30行!当然,如果 Google 继续改进验证隐藏API调用的方法,这个方式可能会失效,但是目前的机制没有问题。

参考链接


Android多用户模式下获取当前UserId的方式

1. Linux uid/gid

Linux下的用户id(uid)和群组id(gid)。Linux是多用户系统,每个用户都拥有一个uid,这个uid由系统和用户名做映射绑定。同时,为了便于用户管理(譬如管理文档权限),Linux引入了群组的概念,可以将多个用户归于一个群组。每一个群组拥有一个群组id(gid)。 
root用户:Linux下的唯一的超级用户,拥有所有的系统权限。root用户所在的组就是root组。

2. Android uid(4.2(API Level 17))

Android 4.2开始支持多用户。Linux的uid/gid多用户体系已经被用在App管理上。

Android重新开发了一套多用户体系,在UserManagerService中管理,PackageManagerService和ActivityManagerService中也有相关逻辑。Android的多用户可以做到不同用户的应用的物理文件级(数据)的区分,以实现不同用户有不同的壁纸、密码,以及不同的应用等。

例如:在一个有两个用户(用户id分别为0和10)的安卓设备上,在用户10下安装一个应用,此时,在0下是看不到这个应用的。

从data/system/packages.xml查看此应用的uid:userId=”10078”

Process.myUid()得到uid为”1010078”

Process.myUserHandle()得到”userHandle{10}”

在另一个用户0下安装此应用。

查看packages.xml,看到uid没有变化10078

Process.myUid()得到uid为”10078”

Process.myUserHandle()得到”userHandle{0}”

adb shell进入命令行,分别查看data/user/0和data/user/10下面此应用的数据区:

用户0: 

 

用户10:

 

可以看到,实际上应用在内部虽然有多用户,但只有一个uid,在不同的用户下,通过uid和用户id合成一个新的uid,以保证在每个用户下能够区分。 

(可以看到文件拥有者是u0_a78,所在群组为u0_a78。从data/system/packages.xml根据包名查看此应用信息,可以看到:userId=”10078”。)

3. android.os.UserHandle

这个类对外提供有关多用户的接口。 从里面的一些api代码可以看到uid在多用户下的处理逻辑:

多用户支持开关: 

注意一个api getUid()。这就清楚了,将用户id 10作为第一个参数,packages.xml中记录的该应用的uid 10078作为第二个参数传入,得到了这个应用在10用户下的uid——1010078! 


 

通过应用的uid得到当前用户的userId,以上过程的逆过程: 

 

从另一个核心的api myUserId()更能清楚地看到应用uid和用户id的关系: 

 

当一个应用使用UserHandle.myUserId()来获取当前的用户id的时候,其实就是从他自己的进程得到应用的uid,然后通过上述逻辑计算出当前的用户id。 

从Process.myUserHandle()也能清楚地看到这个逻辑:

从概念和API命名上,确实有些混乱,但Android也情非得已,Process的API Level是1,UserHandle的API Level是17,可见在最初的Android上面,已经将Linux uid/gid给了应用id了,当时应该也没有考虑Android有一天需要支持多用户。直到4.2(API Level 17),引入了多用户时,已经是若干年过去了,Process已经被无数的开发者使用,无法改变。只能接受这个概念上混淆了。 

可以用如下的几点来简单地澄清这些id概念: 

  1. Process中的xxid相关的概念和API是关于应用id的。 
  2. UserHandle中的xxid相关的概念和API是关于Android用户id的。 
  3. Process有接口得到UserHandle实例。

4. 应用层获取UserId

有时候,我们需要根据不同的用户ID来进行兼容性处理,比如魅族的系统在分身模式下,生物识别相关的Keystore调用(setUserAuthenticationRequired(true))会抛出异常。

我们需要针对这种情况进行兼容性处理,已知的是,魅族的应用分身模式下,用户的ID一定是 999

Process.myUserHandle() 可以得到 UserHandle 对象,但是却不能直接从 UserHandle 对象中获取到用户ID

目前有三种已知的做法

  1. android.os.Process.myUid()/100000 这行代码的原理是依据 Process.myUserHandle() 实现的代码进行逆向操作来获取到真正的用户ID,如果不了解源代码的人会感觉莫名其妙。不需要特殊权限,但是总感觉不够优雅。

  2. ActivityManager.getCurrentUser() 需要申请权限,需要系统应用,需要反射调用。感觉更不优雅了。

  3. UserHandle.myUserId() 不需要特殊权限,需要反射调用。这个感觉也不够优雅。但是当看到androidx.os.UserHandleCompat 也是通过反射调用这些函数的时候,瞬间感觉无所谓了。
    代码参考如下:

参考链接