Android:Installed Build Tools revision 33.0.2 is corrupted.

使用33.0.2及以上版本的build-tools编译Android应用时。

有些人会按照提示去SDK Manager中重新安装build tools,然后发现这样做是无用的

编译时会收到:

Windows:

Linux/macOS:

解决方案:

更改批处理文件名称

Windows系统:

  1. 找到build tools目录中的d8.bat,将文件名修改为dx.bat。
  2. 找到build tools目录中的lib/d8.jar,将文件名修改为dx.jar。
  3. 回到Android Studio重新打包。

Linux/macOS系统:

  1. 找到build tools目录中的d8,创建软链接 ln -s d8 dx
  2. 找到build tools目录中的lib/d8.jar,创建软链接 ln -s d8.jar dx.jar
  3. 回到Android Studio重新打包。

参考链接


Android:Installed Build Tools revision 33.0.2 is corrupted.

使用UrlQuerySanitizer来处理URL

网上对于 UrlQuerySanitizer 的资料比较少,这个是 Android 提供的一个用来处理 url 的 API。由于项目的需要,需要对 url 的 query 参数进行排序,因此需要解析 url 并处理 query 参数。

最初的方法是使用 Uri:

通过这样的方式就可以解析 url,并获取到各个 query 参数。但后来发现 Uri 不能处理一些特殊字符,比如#,Uri 会截断#以后的内容,这样就不能满足开发需求。经过各种 google,最后发现了一个 UrlQuerySanitizer 的 API:

首先要使用 setAllowUnregisteredParamaters 让其支持特殊字符,然后使用 setUnregisteredParameterValueSanitizer 来设置支持哪些特殊字符,UrlQuerySanitizer 提供了集中默认的 ValueSanitizer:

每种 ValueSanitizer 都对应过滤哪些字符,被过滤掉的特殊字符会被替换成_或者空格。
如果默认的 ValueSanitizer 不能满足开发需求,还可以自己构造 ValueSanitizer:

UrlQuerySanitizer 也可以通过 key 来获取相应的 value,比如给一个 url:http://coolerfall.com?name=vincent:

UrlQuerySanitizer 还可以只解析 query 参数,比如:name=vincent&article=first:

以上就是 UrlQuerySanitizer 大致用法,用来解析处理 url 非常的方便。

参考链接


使用 UrlQuerySanitizer 来处理 url

macOS Sonoma(14.2.1)通过UTM虚拟机编译Android 12.1源码过程总结(MacBook Pro 2023-Apple M2 Pro)

前置条件


根据 Google 官方文档,2021年6月22日之后的Android系统版本不支持在macOS系统上构建,我们在 Applic SiliconmacOS 系统是不能直接成功构建后续版本的,但是之前的版本可以在修改编译配置后成功编译,只是是否能正常运行存疑

尝试过使用 Podman Desktop / Docker 方式进行编译、也尝试过借助 OrbStackLima 这些纯虚拟机通过安装 ubuntu 22.04 系统镜像的方式进行编译,结果都在执行 lunch 命令的时候长时间卡住,观察系统进程发现名为 nsjail 进程的 CPU 占用持续卡住在 100% 上无法继续编译,并且由于 Docker 或者虚拟机文件系统是 Linux 文件系统,而宿主机的文件系统是 AppleFS 文件系统,导致需要进行文件转换,中间的转换性能代价非常高,性能很差。

相反,目前测试来看,直接在 UTM 虚拟机里执行编译的性能反倒更好一些。

目前测试发现存在严重的文件系统缺陷,编译/大量文件复制过程中,经常出现文件系统损坏,导致编译失败。

原因参考:

https://github.com/utmapp/UTM/pull/5869
https://github.com/utmapp/UTM/pull/5919

需要等待 UTM 合并到主分支。

另外,我们需要安装 Rosetta 2 支持运行部分 x86_64 应用。注意  Rosetta 2 只支持 64 位应用,不支持 32 位应用。 参考 Does Rosetta 2 support 32-bit Intel apps?

继续阅读macOS Sonoma(14.2.1)通过UTM虚拟机编译Android 12.1源码过程总结(MacBook Pro 2023-Apple M2 Pro)

macOS Ventura(13.6)/macOS Sonoma(14.0)编译Android 10.0/Android 11.0源码过程总结(MacBook Pro 2023-Apple M2 Pro)

前置条件


  • macOS Ventura(13.6)/macOS Sonoma(14.0) MacBook Pro 2023-Apple M2 Pro (4能效核、8性能核、32GB内存、2TB磁盘)
  • Homebrew (4.0.28 或更高版本)
  • Xcode Version 15.0 (15A240d)
  • Android Studio Giraffe | 2022.3.1 Patch 1

从Intel版本MacBook Pro迁移到MacBook Pro 2023(Apple M2 Pro)的设备,参考 从Intel版本MacBook Pro 2013迁移到MacBook Pro 2023(Apple M2 Pro)后HomeBrew报错"Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)" 重新安装 Homebrew

根据 Google 官方文档,2021年6月22日之后的Android系统版本不支持在macOS系统上构建,我们在 Applic SiliconmacOS 系统是不能直接成功构建后续版本的,但是之前的版本可以在修改编译配置后成功编译。

尝试过使用 Podman Desktop / Docker 方式进行编译、也尝试过借助 OrbStackLima 这些纯虚拟机通过安装 ubuntu 22.04 系统镜像的方式进行编译,结果都在执行 lunch 命令的时候长时间卡住,观察系统进程发现名为 nsjail 进程的 CPU 占用持续卡住在 100% 上无法继续编译,并且由于 Docker 或者虚拟机文件系统是 Linux 文件系统,而宿主机的文件系统是 AppleFS 文件系统,导致需要进行文件转换,中间的转换性能代价非常高,性能很差。

通过 UTM 虚拟机,使用 MacOS 提供的虚拟机执行编译的话,性能会更好。但是目前测试发现存在严重的文件系统缺陷,编译/大量文件复制过程中,经常出现文件系统损坏,导致编译失败。

需要在 M2 上使用UTM 虚拟机编译的,可以参考 macOS Sonoma(14.1.1)通过UTM虚拟机编译Android 11.0源码过程总结(MacBook Pro 2023-Apple M2 Pro) 通过 UTM 虚拟机借助 Rosetta 2 的方式进行编译。目前测试来看,性能勉强能用。

另外,我们需要安装 Rosetta 2 支持运行部分 x86_64 应用。注意  Rosetta 2 只支持 64 位应用,不支持 32 位应用。 参考 Does Rosetta 2 support 32-bit Intel apps?

继续阅读macOS Ventura(13.6)/macOS Sonoma(14.0)编译Android 10.0/Android 11.0源码过程总结(MacBook Pro 2023-Apple M2 Pro)

解决 Only fullscreen opaque activities can request orientation

这段时间把App的targetSDKVersion升级到了27,昨晚上线之后今早看到后台一堆崩溃,全是 Android 8.0 的设备,因为手头设备有限,测试的时候只测了Android 8.1的设备,没想到还有一个这个坑埋在这里,记录一下处理办法。

问题分析

targetSDKVersion为26或者27时,在 Android 8.0 的设备上,一些设置了windowIsTranslucent标志,将背景设为透明,同事将屏幕方向锁定的Activity,会崩溃并抛出这个异常:

这个问题网上有很多讨论以及解决方法,问题的原因出自这里

这里做了当屏幕方向锁定了并且不为全屏并且 App 的targetSdkVersion 大于 Android O的话,就会抛出这个异常。

是否为全屏的判定如下:

手头的 Android 8.1 的机器并没有触发这个问题,是因为这个问题在 8.1 里已经修复了。

解决方案

解决方法有如下几种:

  1. 降级targetSDKVersion到26以下(废话!!)

  2. 移除mainfest文件里的screenOrientation属性

  3. 取消Activity主题里的windowIsTranslucent属性或者windowSwipeToDismiss属性或者windowIsFloating属性(根据你设置了什么属性来具体分析)

  4. (推荐)移除manifest文件里的screenOrientation属性,并在ActivityonCreate方法里设置屏幕方向

参考链接


解决 Only fullscreen opaque activities can request orientation

Android 12 SplashScreen API以及Jetpack兼容库

前言

1、什么是Android的冷启动时间?

冷启动时间是指点击桌面LOGO那一刻起到启动页面的Activity调用onCreate()之前的时间段。

2、冷启动的时间段内发生了什么?

在一个Activity打开时,如果Application还没有启动,系统会创建一个进程,进程的创建和初始化会消耗一些时间,在这个时间中,WindowManager会先加载APP的主题样式里的窗口背景(windowBackground)作为预览元素,然后才会真正的加载布局,如果这个时间过长,会给用户造成一种错觉:APP卡顿不流畅

常见做法

  • 将背景设置为APP Logo,市面上大部分APP都是这么做的

  • 将背景设置为透明色,当点击桌面LOGO时并不会立即启动APP,而是在桌面停留一会(其实已经启动)

上面做法可以达到秒开效果,但属于掩耳盗铃

Android 8.0

Google以前不推荐使用闪屏的使用,但是后来很多APP都在使用闪屏,Google希望让启动屏的制作更简单。

Android Oreo中提供了Splash Screen API,允许开发者把一个drawable资源设置为闪屏。

新建values-v26目录:

通过windowSplashscreenContent设置的drawable资源将会覆盖在windowBackground顶部,在系统状态栏之下,如果不想受到System Bars限制,请使用全屏主题。

继续阅读Android 12 SplashScreen API以及Jetpack兼容库

Android中使用System.exit(0)退出后App又重新启动

System.exit(0):终止当前正在运行的 Java 虚拟机。参数用作状态码;根据惯例,非 0 的状态码表示异常终止。

System.exit(0)正常终止程序,有时候在退出安卓应用会使用到。

使用这个方法如果前面存在没有finish()掉的Activity会重新启动,导致退出失败。

MainActivity代码:

直接启动第二个Activity

NewActivity代码:

此时点击button退出应用重启,修改MainActivity:启动新的Activity,finish存在MainAcitvity

总结:

因为应用栈中还存在别的activity没有finish,导致应用重新启动。

使用System.exit(0)时,确保任务栈中所有activity已经finish。

参考链接


Android中使用System.exit(0)退出后app又重新启动

从Intel版本MacBook Pro 2013迁移到MacBook Pro 2023(Apple M2 Pro)后运行Android模拟器崩溃

MacBook Pro 2023(Apple M2 Pro)Intel 版本 MacBook Pro 2013 通过 TimeMachine 迁移后运行模拟器,启动就崩溃。

崩溃的原因是原来运行的模拟器是通过 Intel HAXM 来加速的,但是 MacBook Pro 2023(Apple M2 Pro) 已经是 ARM 指令集了。这样的组合就诱发了虚拟机的崩溃。

此处,我们需要手工卸载已经安装的 Intel x86 Emulator Accelerator(HAXM installer)Android Emulator 之后重新安装即可解决。

如下图:

继续阅读从Intel版本MacBook Pro 2013迁移到MacBook Pro 2023(Apple M2 Pro)后运行Android模拟器崩溃

Android Studio Flamingo | 2022.2.1 Patch 2 配置Robolectric-3.8/4.3.1/4.5.1/4.6.1单元测试环境

一直通过 Android Studio 3.6.3/4.0/4.1/4.2配置Robolectric-3.8/4.3.1/4.5.1/4.6.1 Powermock-1.6.6单元测试环境 配置 Powermock 进行单元测试。

虽然配置起来稍显复杂,但是也是够用的。

但是当升级到Android Studio Flamingo | 2022.2.1 Patch 2 之后,内置的 Java 版本被升级到 Java 17 ,使用这个 Java 版本执行单元测试,会报错如下:

可是 Powermock 已经长时间没有新版本发布,没有及时跟进 Java 版本的更新。

当时引入 Powermock 的原因是为了解决静态函数的测试问题,但是从 Mockito 3.4.0 版本开始,Mockito 已经支持静态函数测试。

因此,完全可以只使用 Mockto 进行测试。

待测试代码如下:

测试代码如下:

参考链接


Android之FileProvider详解

简介

Android 7.0 之前,文件的 Urifile:// 形式提供给其他 app 访问。

Android 7.0 之后,分享文件的 Uri 发生了变化。为了安全起见,file:// 形式的Uri 不能正常访问。官方提供了 FileProviderFileProvider生成的Uri会以content://的形式分享给其他app使用。

content形式的Uri可以让其他app临时获得读取(Read)和写入(Write)权限,只要我们在创建 Intent 时,使用 Intent.setFlags() 添加权限。只要接收Uriapp在接收的Activity任务栈中处于活动状态,添加的权限就会一直有效,直到app被任务栈移除。

目的

7.0 以前,为了访问 file:// 形式的 Uri,我们必须修改文件的权限。修改后的权限对所有 app 都是有效的,这样的行为是不安全的。content://形式的UriAndroid的文件系统更安全,对于分享的文件,接收方 app 只拥有临时的权限,减少了我们app内部的文件被其他 app 恶意操作的行为。

使用

创建FileProvider

manifest文件<application>标签中添加pvodier标签,配置如下。

android:name指定Provider所在的位置。官方自带的FileProvider已经相当完善,所以我们不需要像ServiceBroadcast一样自定义,直接使用自带的就行,直接输入privoder会自动出现提示。

android:authorities相当于一个用于认证的暗号,在分享文件生成Uri时,会通过它的值生成对应的Uri。值是一个域名,一般格式为<包名>.fileprovider

android:exported设置为falseFileProvider不需要公开。

android:grantUriPermissions设置为true,这样就能授权接收端的app临时访问权限了。

设置共享目录

res/xml中创建一个资源文件(如果xml目录不存在,先创建),名字随便(一般叫file_paths.xml)。

<paths>必须有1个或多个子标签,每个子标签代表要请求的私有文件目录。不同的子标签代表不同的目录类型。

<provider>标签中添加<meta-data>子标签。

设置<meta-data>的属性android:name值为android.support.FILE_PROVIDER_PATHS,属性android:resouce的值为刚才我们创建的path文件名。

配置paths

<paths>的每个子标签必须有path属性,代表content Uris的路径。name不需要和path保持一样,只是一个名称。

子标签有以下几种。

files-path

代表内部存储的files目录,与Context.getFilesDir()获取的路径对应。

最终生成的Uri格式为:authorities/pathname/filename

示例:

cache-path

代表内部存储的cache目录,与Context.getCacheDir()获取的路径对应。

external-path

代表外部存储(sdcard)的cache目录,与Environment.getExternalStorageDirectory()获取的路径对应。

external-files-path

代表app的外部存储的根目录,与Context#getExternalFilesDir(String) Context.getExternalFilesDir(null)获取的路径对应。

external-cache-path

代表app外部缓存区域的根目录,与Context.getExternalCacheDir()获取的路径对应。

external-media-path

代表app外部存储媒体区域的根目录,与Context.getExternalMediaDirs()获取的路径对应。

注意: 这个目录只在API 21(也就是Android 5.0)以上的系统上才存在。

生成Content Uri文件

为了让其他app使用Content Uri,我们的app必须提前生成Uri

这里注意获取目录,在配置paths时我们讲了,paths的子标签必须和获取目录的代码保持对应。这里我们用的是Context.getFilesDir(),所以paths文件中必须包含files-path子标签,不然别的app获取uri时会出现异常。

最终生成Uri是使用的FileProvider.getUriForFile()。第一个参数就是provider中设置的authorities属性值。

授权临时权限

分享一般只有这读取和写入2种权限,根据需要传入Intent.addFlags()中。

Uri传入Intent

有好几种传入的方式,根据不同的场景使用不同的方式。

为邮箱app分享附件文件

其他分享

使用Intent.setDateIntent.setClipData()

最后使用startActivity(intent)启动分享操作。

参考链接


Android之FileProvider详解