android难点技术（Android13最前沿扶我起来）

8月16日，谷歌宣布Android13新系统的源代码已经上传到Android开源项目（AOSP）中，Android13正式发布。自从2022年2月Android13第一个预览版上线以来，历经7个月的测试和优化，正式版本的Android13终于来了！Android13仍然聚焦个人隐私保护和安全，并提供了万物互联时代下大小屏适配、电池利用率优化等相关的技术开发能力。

感兴趣的开发者可以登录官网下载源码测试学习：https://developer.android.google.cn/about/versions/13

Android13正式版发布后，使用模拟器进行了研究和适配测试。本文将从权限变更、系统优化、功能更新等方面来谈谈Android13新特性，以帮助开发者快速上手完成Android新系统的适配。

一、权限变更

1.1、通知权限

通知栏消息一直是App和用户沟通的有效渠道。在Android13之前，App只需要使用NotificationManager即可向终端用户推送通知栏消息。Android13则引入了新的运行时通知权限：POST_NOTIFICATIONS。对此，App开发者需要予以重点关注。

对该权限进行了测试，总结如下：

1. 首先看TargetSdk<33的情况。

如下图，当App使用通知栏功能时，系统将自动弹出授权弹窗：

用户点击“允许”，App可正常给用户推送消息：

2. 再看TargetSdk == 33的情况。

开发者需要在AndroidManifest.xml中声明POST_NOTIFICATIONS权限，还需要在使用通知栏推送功能时在代码中申请运行时权限：

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" package="com.gt.demo.mubai.push"> <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/> </manifest> requestPermissions(new String[]{“android.permission.POST_NOTIFICATIONS”})

以上是用户点击“允许”App推送的情况。当然，用户也有可能点击“不允许”。值得注意的是，一旦被用户拒绝授权，下次系统将不会再出现权限申请的弹窗。

如果App仍然要推送重要消息（比如重大版本更新）给用户，则需要引导用户前往设置界面打开通知权限。代码如下：

private void jumpNotificationSetting() { final ApplicationInfo applicationInfo = getApplicationInfo(); try { intent intent = new Intent(); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); intent.setAction("android.settings.APP_NOTIFICATION_SETTINGS"); intent.putExtra("app_package", applicationInfo.packageName); intent.putExtra("android.provider.extra.APP_PACKAGE", applicationInfo.packageName); intent.putExtra("app_uid", applicationInfo.uid); startActivity(intent); } catch (Throwable t) { t.printStackTrace(); Intent intent = new Intent(); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); intent.setAction("android.settings.APPLICATION_DETAILS_SETTINGS"); intent.setData(Uri.fromParts("package", applicationInfo.packageName, null)); startActivity(intent); } }

★温馨提示：

如果App要确认用户是否已启用通知，可以调用NotificationManager.areNotificationsEnabled()进行判断。

另外，除了“允许”和“不允许”两种选择外，用户还可以划走权限申请对话框（User swipes away from dialog），即用户未选择授权（也未选择不授权）。那么下次App进行通知栏消息推送时，系统将再次弹出用户授权弹窗。

Android13的通知权限变更将使终端用户的体验得到极大改善。用户能够自主选择是否接受App推送的通知栏消息，减少被无效信息频繁打扰的情况。

我们一直倡导绿色推送，强调在合适的时间、合适的地点、合适的场景把合适的内容推送给合适的人群，给终端用户更好的体验。

1.2、WiFi权限变更

Android13对WiFi权限的变更也是一大重点。在万物互联的当下，不同的智能家居/智能穿戴设备多是通过WiFi互通互联，因此这些类型的App开发者更要着重关注该部分内容。

在以往版本的Android系统下，如果App要使用WiFi相关功能，需要申请 ACCESS_FINE_LOCATION，即位置权限，如下图：

▲图片来源于Android13官网

为了避免App过度索权，更好地保护终端用户隐私，Android13将WiFi权限从位置权限中分离了出来，引入了新的运行时权限：NEARBY_WIFI_DEVICES。

如果App仅需要使用WiFi相关的API，并不需要使用getScanResults()、startScan()等与位置相关的API，那么建议App开发者切换到新的NEARBY_WIFI_DEVICES权限。

新的WiFi权限运行机制：

▲图片来源于Android13官网

权限使用和适配：

开发者需要注意的是，如果你的应用（targetSdk == 33）已经声明不会根据 WiFi信息推导设备的物理位置信息，那就不再需要声明 ACCESS_FINE_LOCATION 权限。

另外，如果应用在Android13上只使用WiFi API而不使用位置信息，那开发者可以在AndroidManifest.xml中增加NEARBY_WIFI_DEVICES权限，并将usesPermissionFlags属性设为neverForLocation，给ACCESS_FINE_LOCATION权限增加maxSdkVersion="32"的限制，代码如下：

<manifest ...> <uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES" android:usesPermissionFlags="neverForLocation"/> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" android:maxSdkVersion="32" /> </manifest>

1.3、更细分的媒体权限

除了通知权限和WiFi权限的更新外，Android13对本地数据访问权限也做了进一步细化。

Android13将READ_EXTERNAL_STORAGE和 WRITE_EXTERNAL_STORAGE权限细分为：READ_MEDIA_IMAGES、 READ_MEDIA_VIDEO和 READ_MEDIA_AUDIO，如下图：

▲图片来源于Android13官网

使用android.permission.READ.MEDIA_IMAGES，对新权限进行了测试：

我们发现，单独请求READ_MEDIA_IMAGES、单独请求 READ_MEDIA_VIDEO和同时请求READ_MEDIA_IMAGES& READ_MEDIA_VIDEO，系统均将只显示一个授权弹窗。

另外，如果App（targetSdk == 33）已经申请了读的权限，那App同时也就有了写的权限，无需再额外声明 WRITE_EXTERNAL_STORAGE权限，代码如下：

<manifest ...> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" /> <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> </manifest>

1.4、精确的闹钟权限

为了节省系统资源，Android12引入了SCHEDULE_EXACT_ALARM权限进行“闹钟和提醒”功能的授权管理。Android13则又引入了新的闹钟权限USE_EXACT_ALARM。

和Android12的SCHEDULE_EXACT_ALARM权限不同，如果App已经申请使用了USE_EXACT_ALARM新权限，那么用户是不能在设置页面里关闭授权的。

对于日程管理、时间管理等类型的App来讲，Android13引入的USE_EXACT_ALARM权限能够带来一定便利。相比Android12的SCHEDULE_EXACT_ALARM权限，使用新权限的应用将不再需要频繁打扰用户进行授权，能够更高效地为用户提供闹钟、日程提醒等服务。

不过，为了防止新权限被滥用，GooglePlay设置了严格的上架审核机制。开发者要注意，一旦使用了USE_EXACT_ALARM权限，App在上架GooglePlay时将会被平台严格审查。除非App属于闹钟、计时器、日历等类型的应用或者在已被列入到应用市场的白名单里，否则GooglePlay将不会允许使用该权限的应用上架。

随着我国对App用户个人权益保护力度的不断加大，相信后续国内的手机厂商和应用市场也将跟进建立相应的审查机制，增强对用户权益的保护。建议App开发者持续关注相关动态，及时做好适配工作。

1.5、后台的传感器权限

如今生物信息安全也是大众关注的焦点。为了更好地保护终端用户的个人生物信息，Android13增加了新的后台传感器权限。

App在后台运行时，如果需要获取心率、体温、血氧饱和度等传感器信息，将不仅需要向用户申请现有的BODY_SENSORS权限，还必须声明新的BODY_SENSORS_BACKGROUND权限。

综上可以看到，Android13对个人隐私保护的重视和加强。除了权限变更方面，Android13还进行了系统优化、组件更新，以进一步提升系统的安全性和友好性。

二、系统优化

2.1、更安全的系统组件

2.1.1、IntentFilter

在之前版本的Android系统中，开发者只需将android:exported设为true就可以跨应用显式启动Activity和Service，即使intent-filter中的action或者type不匹配，也能够启动。

为避免上述漏洞，Android 13增强了intent-filter的匹配过滤逻辑。在接收方的targetSdk == 33的情况下，如果intent-filter匹配命中，无论发送方的targetSdk版本如何，intent都将生效。

★温馨提示：

以下几种情况不需要遵循intent-filter的匹配过滤逻辑：

• 组件没有声明
• 同一个App里的intent
• 系统或Root进程发出的intent

2.1.2、BroadcastReceiver

以往的Android系统下，应用动态注册的BroadcastReceiver广播接收器会接收到任何应用发送的广播（除非该接收器使用了应用签名权限保护），这会使动态注册的广播接收器存在安全风险。

Android13要求，应用动态注册的广播接收器必须以显著的方式指出是否允许其他应用访问，即其他应用是否可以向其发送广播。否则，在动态注册时系统将抛出安全异常（SecurityException）。

目前该增强措施并非默认生效，开发者需启用 DYNAMIC_RECEIVER_EXPLICIT_EXPORT_REQUIRED兼容性框架，并在动态注册广播时指定是否接受其他应用的广播：

context.registerReceiver(receiver, intentFilter, RECEIVER_EXPORTED) context.registerReceiver(receiver, intentFilter, RECEIVER_NOT_EXPORTED)

★温馨提示：

系统广播不受RECEIVER_NOT_EXPORTED影响。

2.2、前台服务(FGS)任务管理器

Android13还新增了前台服务（FGS）任务管理器功能。

如下图，用户可以在下拉的通知栏中直接关闭前台服务和应用程序：

此外，如果系统检测到应用长时间运行某项前台服务（在24小时的时间段内至少运行20小时），便会向用户发送提醒通知，通知内容如下：

APP is running in the background for a long time. Tap to review.

值得注意的是，满足以下任一条件的情况下，系统均将不会显示该通知：

• 已经发送过前台服务相关的通知，也就是说，用户未关闭之前的提醒通知
• 前台服务的类型为 FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK 或 FOREGROUND_SERVICE_TYPE_LOCATION

★温馨提示：

如果系统针对某应用已经显示过此通知，那至少在30天后系统才会再次显示该通知。另外，系统级应用、安全应用（比如具有android.app.role.EMERGENCY 角色的应用）等运行的前台服务，将不会显示在FGS任务管理器中。

2.3、通知权限

Android9引入了应用待机存储分区功能，根据应用的使用时间和频率，将应用动态分配到五个不同优先级的存储分区，然后对不同存储分区的应用施加不同级别的应用资源限制。

如下，存储分区按照优先级从高到低排序，优先级越低对该分区内的App限制越多：

• 活跃：应用目前正在使用中，或者最近刚刚使用过。
• 工作集：应用会定期使用。
• 常用：应用会经常使用，但不会每天使用。
• 极少使用：应用不经常使用。
• 受限：应用会消耗大量的系统资源，或表现出不良行为（Android11引入）。

其中“受限”状态的应用，将受到以下限制：

• 无法启动前台服务。
• 现有的前台服务会从前台移除。
• 不会触发闹钟。
• 不会执行Jobs。

在Android9应用待机存储分区功能的基础上，Android13对电池资源策略进行了优化，以延长设备的电池续航时间，提升终端用户的体验。

首先，Android13新增了以下规则，符合相应规则的应用将进入到“受限”存储分区（设备处于关闭状态的时间不会计入互动限制）：

• 用户已经8天没有与应用互动。
• 应用在1天内调用过多的广播或者绑定服务。
• 应用在1天内消耗了大量的电池电量，阈值取决于设备。

其次，Android13还对“受限”存储分区的应用增加了限制措施：

• 应用将不收受到BOOT_COMPLETED、LOCKED_BOOT_COMPLETED广播

2.4、对non-SDK接口限制的更新

Android 13对一些non-SDK接口进行了限制（并针对部分限制提供了替代方案）。开发者需要明确App在升级时是否使用了受限的non-SDK接口。

Android13中受限的non-SDK接口参考：

Landroid/app/Activity;->setDisablePreviewScreenshots(Z)V # Use setRecentsScreenshotEnabled() instead. Landroid/os/PowerManager;->isLightDeviceIdleMode()Z # Use isDeviceLightIdleMode() instead. Landroid/os/process;->setArgV0(LJava/lang/String;)V # In general, do not try to change the process name. If you must change the process name (for instance, for debugging), you can use pthread_setname_np() instead, though be aware that doing this might confuse the system. Landroid/view/accessibility/AccessibilityInteractionClient;->clearCache(I)V # Use android.accessibilityservice.AccessibilityService#clearCache() instead.

三、功能更新

用户体验的提升也一直是Android系统更新的重点。Android13主要针对剪切板、大小屏适配、UI展示等进行了功能更新。

3.1、剪切板

首先来看剪贴板。相信大家都使用过剪贴板，它能够快速复制页面上的内容，方便我们进行内容编辑和修改。

但是一直以来，剪切板功能存在这样一个隐患，即剪切板复制的内容中可能存在敏感信息。为了更好地保障剪切板中的隐私内容（比如手机号码、邮箱、账号密码等）不被泄露，Android13对剪切板功能进行了更新。

如下图，Android13剪切板功能的使用分2步：

• 确认内容已成功复制。
• 提供所复制内容的预览。

此外，Android13还提供了脱敏功能，使用户能够对剪切板中的敏感信息进行隐藏，实现了便利性和安全性兼得。

3.2、更好地支持平板和大屏幕

平板电脑、车载大屏、智能电视屏等的广泛应用，使用户的终端场景越来越多样化。如何给不同终端的用户始终美观和流畅的体验？Android13对此提供了更好的支持，对大屏上的系统UI以及分屏展示等进行了更新。

如下图，在大屏幕上，Android13支持不同的功能模块同屏展示，使得大屏幕的优势能够充分被利用。

▲Android13系统下，用户可以将“快速设置”版块和“通知栏”版块置于同屏当中。

3.3、Jetpack WindowManager

另外，Android13还支持用户在大屏幕中一次显示多个Activity，以充分利用大屏的显示空间。

开发者可通过创建XML配置文件或进行Jetpack WindowManager API调用来确定App实现多个Activity同屏显示（比如并排或堆叠）的具体方式。

▲比如，以分割任务窗口（splite task window）的形式实现单个屏幕内展示两个Activity。

3.4、更好的兼容性支持

对于尚未适配大屏幕的App，Android13也提供了更加友好和稳定的兼容支持，让这些App在默认情况下也能有舒适美观的UI展示，不会影响到终端用户的体验，如下图：

▲图片来源于Android13官网

总结

通过近两年的Android系统更新可以看到，Google不再对安卓系统进行大刀阔斧的改动，而是在用户体验、隐私保护、系统安全、组件优化等方面下足了功夫。

更多Android13的更新要点，开发者可进入Android13官网做进一步了解：https://developer.android.google.cn/about/versions/13

这里也分享一些珍藏资源，从面试简历模板到大厂面经汇总，从大厂内部技术资料到互联网高薪必读书单，以及Android面试核心知识点（844页）和Android面试题合集2022年最新版（354页）等等，这些资料整理给大家，希望踩过的坑不要再踩，遭遇的技术瓶颈一次性消灭。

如果需要的话，可以顺手帮我点赞评论一下，直接私信我【笔记】免费领取！

Java部分，像序列化、注解、泛型、反射、JVM、编译时、动态代理等等，都是非常重要的，尤其是越往上走越重要，在大厂中是必问的版块，很多中小厂以及校招也会着重考量Java基础

Kotlin部分，刚推出的时候大家都不太愿意学习，现在官方新文档、Sample代码、大厂面试、实际工作都已经纷纷转向Kotlin了，作为官方主推的语言，国外基本都已经转换过来了，但国内稍显慢半拍。一直到现在，Kotlin已经是一个很明显的趋势了，很多新技术都需要结合Kotlin一起使用，还不上车就晚了。

Jetpack Compose，Jetpack可以让我们可以摆脱不断造轮子抄轮子的窘境，而Compose作为Google I/O 2019 发布的新的声明式的UI框架，目前API已经稳定，构建、预览等开发体验也已经趋于完整，新的声明式UI开发也已是共识，必将是日后App极为重要的编程方式。

Framework，作为框架层，给我们提供了很多的API，但很多机制都是封装好直接用的，如果不深入了解原理的话，很难在这基础上进行优化。Framework的学习不是一蹴而就的，但是当你慢慢理解的时候，就会发现很多日常工作中的问题都迎刃而解了。更何况，兄弟们，面试必问啊！！！

也可以继续向下，Framework开发、SDK开发，不过岗位会比应用要少一点，不过薪资和稳定性会更好一点

如果需要的话，可以顺手帮我点赞评论一下，直接私信我【笔记】免费领取！

性能优化，这块就是软件工程的深水区，也是衡量一个开发技术水平的标准。因为想要搞懂性能优化，必须对各种底层原理有着很深的了解，各种case要有非常丰富的经验，不管是APP从0到1还是从1到N，都离不开性能优化。也是面试中最容易考验出个人技术功底的部分

很多大厂的性能优化专家，真的是可以当大爷……

开源框架 架构设计，各个开源框架，除了会用之外还要主动学习其底层原理、设计思想，一方面是因为面试中经常会问到，一方面也是因为在大厂中，很容易遇到需要自己写框架的情况。相关的原理以及对架构、设计模式的理解，在高工岗是不可或缺的。

退可高工，进可架构，但作为架构师的话，对于知识的广度又有要求了

车载，最近很火的细分领域，也可以说是Android的又一春，对于底层要求会更高一点，涉及Framework固件烧写、System UI、桌面程序、底层 Window Display、底层协议USB通信、硬件以及串口通信、蓝牙通信

身边也有转车载的，薪资很香！

音视频，这块自疫情那段时间就突然走上了风口，一方面是突发事件带来的风口，一方面也是5G的带宽带来更好的体验，各厂纷纷入局，但由于音视频这块自学比较困难，很难招到合适的候选人，自然薪资也是水涨船高

涉及C/C 、JNI、H.264、H.265、OpenSL、OpenGL、编解码、网络协议、WebRTC、FFmpeg、IJKPlayer、librtmp等等

跨平台开发，跨平台框架主要解决的是UI和部分业务逻辑的跨平台，和平台相关的比如蓝牙、平台交互、数据存储、打包构建等都离不开原生支持。

所以跨平台和原生是共生的关系，如果原生都没了，我们还跨个der？该不会跨WinPhone吧？

跨平台作为一个老生常谈的问题，主要是增加代码复用，减少我们对多个平台差异适配的工作量，降低开发成本（可能主要是为了企业降本增效~）

尤其是在中小厂，成本有限的情况下，或许会更加倾向于原生开发掌握Flutter的情况

很多大厂也都已拥抱Flutter，掌握Flutter不仅可以帮助到面试，也可以拥抱跨端开发

如果需要的话，可以顺手帮我点赞评论一下，直接私信我【笔记】免费领取！

,