语音交互并不是一个新事物，很早就有了。比如 Apple 设备的 、Amazon 的 、Google 的等等。它们大多是系统的内置服务，由热词唤醒或按键触发，之后只通过语音指令即可完成完整的交互。可这些交互场景往往覆盖了系统服务或系统 App，而对第三方 App 的支持有限或者鲜少针对第三方 App 完成完整的语音交互逻辑。第三方 App 除了被动等待系统语音服务的调度，当然可以选择主动支持。可是完

Android 12上全新的应用启动体验改进的应用启动体验 - Android 12 中应用启动的体验更加一致，更令人愉悦。我们为所有应用添加了新的应用启动动画，在启动时屏幕会显示应用图标，并过渡到应用本身。新的体验为每个应用的启动带来了标准化的设计元素，但我们也允许进行定制，以便应用保持自己独特的品牌特色。例如，您可以使用新的 SplashScreen (启动屏幕) API 和资源来管理启动屏幕

之前探讨过的和存在module的限制，但其主要用于密封 class 的扩展和 interface 的实现。如果没有这个需求只需要限制 module 的话，使用 Kotlin 中独特的internal修饰符即可。本文将详细阐述 internal 修饰符的特点、原理以及 Java 调用的失效问题，并以此为切入点网罗 Kotlin 中所有修饰符，同时与 Java 修饰符进行对比以加深理解。interna

关于 Android 车机，之前分析过方控上自定义按键的输入机制和中控上旋钮输入的原理，但都局限于 Car Service 内 Input 相关模块。一文了解 Android 车机如何处理中控的旋钮输入从实体按键看 Android 车载的自定义事件机制本文将结合 Android 系统整体，对 CarService 的构成和链路对其做一个全面的分析和理解。我们通过一张表格来总结 CarService

一文了解 Android 车机如何处理中控的旋钮输入从实体按键看 Android 车机的自定义事件机制深度入门 Android 车机核心 CarService 的构成和链路本篇文章我们聚焦 Android 车机上最重要、最常用的接口：即车辆属性。并结合车窗升降这种典型的场景来探究它的完整链路。App 先通过 Car lib 拿到CarService的Car实例，CarService 会初始化所有

Google 最近发布的Gemini模型在全球引起了巨大反响，其在多模态领域的 Video demo 无比震撼。对于 Android 开发者而言，其中最振奋人心的消息莫过于模型将内置到 Android 系统当中，并开放给开发者使用。事实上，能够自研LLM大模型的企业屈指可数，大多数的企业或个人都是在搞基于 LLM 的应用创新。而各大模型们各自为政，提供的能力、对接方式都参差不齐，即便在应用这个维度

监听截屏 API 的使用简单、清晰，以后不需要再通过监听媒体文件的变化等逻辑来迂回实现，采用官方的方式去探测用户的截屏操作并按照文件读写的规范去提取文件。但需要留意 adb、代码、AS 等方式发起的截屏无法通过该 API 监听得到，笔者以为这些不属于用户操作，没有必要纳入到监听范围中。另外，这个监听 API 并不是级别的，每个目标Activity都得注册，所以可以考虑在中完成 API 的注册和注销

Android 13 针对包括手机、大屏、折叠屏等 Android 设备推出了可预见型返回手势（）特性。该特性将便于用户在返回完成之前可以先预览到目标画面或结果，这样的话可以允许他们决定是否要继续返回或者放弃并停留在当前画面。另外引入关于KeyEvent 相关的一系列变更。为节省篇幅和统一认识，后续的相关描述将按照如下规则简称：后续将按照如下几个方面去阐述：简单来说会产生如下影响：备注：无关 ，运

一般来说按照文档的建议去做，出现问题的概率很低。但很多人的情况不同，每每会发生意外状况，就比如这次没有使用 AppCompat 主题引发的坑！AppCompat 框架作为 Jetpack 集合的基石，非常重要。Android Studio 上创建的默认项目都会自动集成 AppCompat 框架，并采用其提供的 AppCompatActivity 作为 Activity Base。App 侧给 Ac

作者：李龙、TechMerger 君在看这个变更之前，我们需要回忆下 Android 12 的一个安全性变更， 即声明了 <intent-filter> 的Activity、BroadcastReceiver、Service 必须声明 android:exported， 否则将会无法被启动。Android 12 的这个变更是为了防止开发者在不知情的情况下，声明了一个 intent-fi