企业官网建设流程全解析

AABrowser 是一款专为 Android Auto 车机大屏打造的开源 WebView 浏览器，它用不到 2000 行核心声明，展示了车载第三方应用开发的完整链路：如何通过distractionOptimized声明让应用"上车"、如何设计一套克制的权限清单，以及如何借助 Obtainium 实现免应用商店的自动更新分发。本文以一个真实项目为样本，带你把这条流程完整走一遍。

一、AABrowser 是什么：把浏览器装进车机

AABrowser 定位非常明确——停车场景下的车机浏览器。它基于 Android WebView 构建，提供 Material 3 动态色彩界面、多标签页、快捷链接主页、书签与二维码分享等能力，最低要求 Android 15（minSdk = 35），正好对应目前主流 Android Auto 车机系统的版本。

对普通开发者最有价值的地方在于：它是一个可以直接打开源码对照学习的 Android Auto 第三方应用样本，从清单声明到 UI 交互、再到发布更新，全链路都是开源可查的。

如果需要在本地跑起来，仓库地址为https://gitcode.com/gh_mirrors/aab/AABrowser，克隆后即可用 Android Studio 构建。

二、关键第一步：在 AndroidManifest 中完成"上车"声明

Android Auto 并不是想装就能装的。系统会检查应用是否符合车载安全规范，而检查的依据几乎全部来自 AndroidManifest.xml。

1. distractionOptimized：行车干扰优化声明

这是整个清单里最核心的一段 meta-data 声明：

<meta-data android:name="distractionOptimized" android:value="true" /> <meta-data android:name="android.max_aspect" android:value="4.0" /> <meta-data android:name="androidx.car.app.minCarApiLevel" android:value="7" /> <meta-data android:name="com.google.android.gms.car.application" android:resource="@xml/automotive_app_desc" />

逐项拆解：

需要注意的细节是：AABrowser 把distractionOptimized和max_aspect在<application>层和 MainActivity 的<activity>层各声明了一次。这是防御性写法——确保无论系统读取哪一级配置，声明都生效。

2. automotive_app_desc.xml：声明支持的模板

上面最后一条 meta-data 指向的 automotive_app_desc.xml 只有短短一行：

<automotiveApp> <uses name="media" /> </automotiveApp>

它告诉 Android Auto：本应用以media（媒体）模板运行。浏览器在车机上不提供导航能力，媒体模板是最贴合的归类。

3. intent-filter：CAR_LAUNCHER 与 APP_MAPS 类别

应用能不能出现在车机主屏的"App 抽屉"里，取决于 intent-filter 里这两类类别的注册：

<category android:name="android.intent.category.CAR_LAUNCHER" /> <category android:name="androidx.car.app.category.NAVIGATION" /> <category android:name="android.intent.category.APP_MAPS" />

• CAR_LAUNCHER让应用进入车机应用列表；
• NAVIGATION+APP_MAPS则让它能被车机以"可占据大屏"的方式唤起；
• 第二个 intent-filter 还注册了http/https的BROWSABLE行为，让应用可以响应网页链接。

更值得学习的是紧随其后的 layout 节点：

<layout android:defaultWidth="800dp" android:defaultHeight="480dp" />

它声明了应用被车机唤起时的默认窗口尺寸（800dp × 480dp，正好 5:3 横屏），让车机调度器无需猜，直接给一块合适的屏幕区域。

4. UI 侧配合：Compose 大触控目标

声明只是"入场券"，真正兑现distractionOptimized承诺的是 UI。AABrowser 用 Jetpack Compose + Material 3 构建界面（版本管理见 libs.versions.toml），所有按钮都是为大屏幕触控设计的大面积卡片：

菜单里的"Request full screen（请求全屏）"开关也很有意思：车机应用默认跑在分屏区域，用户确认停车后才能切全屏——这正是"行车模式"与"停车模式"分离的典型实现。

三、权限设计：一个浏览器到底需要哪些权限

AABrowser 的 权限清单 是车载应用权限设计的克制样本，共 9 项，可分为四类：

三个值得新手记住的设计点：

1. 危险权限按需索取，而非启动即申请。定位和录音权限只在对应功能触发时才弹窗，由 PermissionManager 统一调度。
2. Car 专属权限写在清单里即可：ACCESS_SURFACE和MAP_TEMPLATES属于 Android Auto 体系内的受控权限，不需要用户授权，但必须显式声明，否则 Car App Library 的能力直接不可用。
3. 明文 HTTP 需要单独放行。车机环境中偶尔会遇到 HTTP 站点，AABrowser 通过 network_security_config.xml 全局允许 cleartext 流量，并信任用户自装证书，同时配合 CleartextNavigationHandler 在页面内做安全提示，而不是简单粗暴地"全放行"。

四、Obtainium 分发全流程：没有应用商店也能自动更新

AABrowser 未上架 Google Play，却实现了"安装一次、自动跟版"的体验，核心是把GitHub Releases 当作应用商店，再交给 Obtainium 做扫描与分发。这条链路可以拆成三步。

1. 构建环节：APK 标准化命名

Obtainium 靠文件名里的版本号识别发布。AABrowser 在 build.gradle.kts 中注册了一个RenameApkTask，把 Gradle 默认产物重命名为规范格式：

AABrowser-3.3.apk // 正式包 AABrowser-3.3_debug.apk // 调试包

其中3.3来自 versionName（versionCode 同步维护为 10），保证文件名、版本号、语义版本三者一致。

2. 安装环节：Obtainium 订阅仓库

用户把 AABrowser 仓库地址填入 Obtainium 后，它会周期性拉取 Releases 并解析出最新 APK。推荐参数（也是 README 中 Obtainium 链接所携带的配置）包括：

• preferredApkIndex = 0：取附件列表第一个 APK（即autoApkFilterByArch按设备架构过滤后的主包）；
• versionDetection = true：从文件名提取版本号做比较；
• fallbackToOlderReleases = true：最新 Release 没有可用 APK 时回退到历史版本，避免"卡死在旧版"。

这一步对新手很友好——无需懂构建签名，Obtainium 校验签名一致性后自动安装。

3. 更新环节：应用内双通道版本检查

除了交给 Obtainium，应用自己也内置了更新检查：VersionFetcher 直接查询仓库 API 的releases/latest接口，比对当前versionName，在 VersionCheckSheet 中提示用户"已是最新"或"有新版本"。两条通道互为兜底：Obtainium 负责静默自动更新，应用内检查负责给用户一个主动确认的入口。

五、安全底线：车载应用开发的"第一原则"

最后提醒一个所有车载项目都绕不开的点。AABrowser 在 README 安全章节 中写得很直白：本应用仅供停车时使用，驾驶员请勿注视屏幕。

• 行车中请让乘客使用，或确认车辆停稳后再打开；
• 它依赖distractionOptimized声明获得车机准入，但声明不等于行车中可用的免责，安全规范由使用场景决定；
• 若应用启动失败，官方建议先打开一个导航类应用（如 Waze）再启动，这是车机应用冷启动的一个已知坑。

六、小结

AABrowser 证明了一件事：做一个合格的 Android Auto 第三方应用，难点不在代码量，而在对清单声明、模板体系与分发渠道的理解。对照这份开源样本，你可以在自己的项目中快速搭出同样的骨架，把"上车资格"、权限边界和更新链路一次做对。