项目问题 on Luoj`s Markdown

预置APK

Mon, 08 Jun 2026 16:37:00 +0800

1. 目录结构扫描与功能说明

一级目录	二级目录 (关键)	作用说明	APP 相关标注
amlogic/	`common/apps/`	Amlogic 通用第三方或预置 APP (如 Netflix)	APP 源码/APK 存放地
	`reference/apps/`	Amlogic 参考应用 (如 TVInput, DLNA)	APP 源码存放地
	`common/sepolicy/`	Amlogic 通用 SELinux 策略	权限配置
giec/	`apps/`	GIEC 厂商自定义 APP (如 Glauncher, OTAClient)	核心 APP 存放地
	`common/sepolicy/`	GIEC 厂商自定义 SELinux 策略	权限配置
	`android-certs/`	厂商签名密钥 (platform, shared 等)	签名资源
	`executable/`	厂商自定义脚本与二进制工具	运行辅助
widevine/	`libwvdrmengine/`	Widevine DRM 相关组件	辅助组件

2. 构建文件 (Android.mk/Android.bp) 分析

(1) 预置 APK 模式 (以 Glauncher 为例)

在 Glauncher/Android.mk 中：

Android 系统 Build 阶段 APK 签名机制（通俗笔记）

Mon, 08 Jun 2026 16:36:00 +0800

Android 系统 Build 阶段 APK 签名机制（通俗笔记）

面向：刚接触 AOSP/系统应用开发、需要“系统签名 / system 权限”概念的人
目标：用更直白的方式理解 AOSP 在编译（build）时如何给 APK 签名，以及 如何自定义签名 key、如何让 APK 以 system UID 运行。

原文参考：https://maoao530.github.io/2017/01/31/android-build-sign/

0. 你需要先知道的 3 个概念

签名是干什么的？
Android 用签名来确认“这个 APK 是谁发布/构建的”，并据此决定：
- 是否允许共享 UID（sharedUserId）
- 是否允许同签名应用间共享数据/权限
- 系统应用/特权能力是否能被授予（取决于场景与版本策略）
非对称加密（公钥/私钥）一句话版
- 私钥：必须保密，用来“签名”。
- 公钥：可以公开，用来“验签”。
Build 阶段签名 ≠ Android Studio 打包签名
- 这里讲的是 AOSP 源码编译（make/soong）时，系统在构建流程中对 APK 进行签名。
- Android Studio 的 keystore/gradle 签名属于另一条链路，但原理相通。

1. AOSP 默认有哪些签名 Key？

系统源码里默认准备了 4 组 key，用于在 build 阶段给不同类型的 APK 签名。它们默认位于：

build/target/product/security/

每组 key 都有两类文件：

更换开机动画LOGO

Mon, 08 Jun 2026 16:35:00 +0800

开机LOGO

Z:\android\aml\s905x5\aml-s905x5-androidu-v2\device\amlogic\ross\logo_img_files
OR
Z:\android\aml\s905x5\aml-s905x5-androidu-v2\device\amlogic\common\logo_img_files

取决于TARGET_AMLOGIC_RES_PACKAGE的值

Z:\android\aml\s905x5\aml-s905x5-androidu-v2\device\amlogic\planck\BoardConfig.mk

开机动画路径定义以及查找优先级相关都在这个文件内

Z:\android\aml\s905x5\aml-s905x5-androidu-v2\frameworks\base\cmds\bootanimation\BootAnimation.cpp

Android Init 开机脚本编写指南

Mon, 08 Jun 2026 16:34:00 +0800

Android Init 开机脚本编写指南

以 TiviMateCustom 首启自动安装为例，覆盖 init.rc 编写、shell 脚本编写、SELinux 策略和调试全流程。

一、Android Init 基础

1.1 Init 进程的阶段事件

Android init（PID 1）按固定阶段推进，每个阶段发射一个不可重复的事件：

first_stage
    └── selinux_setup
        └── second_stage
              ├── early-init
              ├── init
              ├── late-init
              │     ├── early-fs
              │     ├── fs
              │     ├── post-fs
              │     ├── late-fs
              │     └── post-fs-data
              ├── early-boot
              ├── boot              ← 文件系统就绪，核心服务准备启动
              └── ...               （Zygote、system_server 等启动）
                                    
              运行时:
              sys.boot_completed=1  ← 开机动画结束，Launcher 就绪

关键区别：

事件类型	触发方式	重放机制	适用场景
阶段事件（`on boot`, `on late-init` 等）	init 内部发射	有 — rc 晚加载也会追溯执行	不依赖属性的初始化
property trigger（`on property:xxx=y`）	属性值变化	无 — 错过就永远错过	rc 必须比属性变化早加载

1.2 RC 文件的加载路径

Init 自动 import 以下目录的 .rc 文件：

Android STB 长按 Power 键弹出关机对话框 — 定位过程总结

Mon, 08 Jun 2026 16:33:00 +0800

Android STB 长按 Power 键弹出关机对话框 — 定位过程总结

背景

在 Android STB（Amlogic S905X5 平台）上，长按遥控器 Power 键会弹出一个系统级关机确认对话框，提示文字为 “Do you want to shut down?"。本文记录如何从现象出发，逐步定位到该对话框的源码位置和触发逻辑。

第一步：通过 dumpsys 获取窗口信息

在 adb shell 中执行：

# 1. 查看当前焦点窗口
dumpsys window | grep mCurrentFocus
# 输出: mCurrentFocus=Window{8fd2b64 u0 android}

# 2. 根据窗口 ID 查看详细信息
dumpsys window windows | grep -A 40 -B 10 "8fd2b64"

关键输出分析

属性	值	含义
`package=android`	属于 `android` 包	这是 Framework 系统级窗口，非第三方 App
`mOwnerUid=1000`	system 进程	进一步确认是系统级
`type=KEYGUARD_DIALOG`	2009	锁屏级对话框，在所有用户上可见
`fl=DIM_BEHIND ALT_FOCUSABLE_IM ...`	半透明背景 + 可获取焦点	典型的模态对话框特征
`Window{8fd2b64 u0 android}`	u0 = user 0	系统用户

结论：对话框是 Android Framework 中的系统级代码弹出的，不是任何 App 的行为。

recovery模式下的reset逻辑修改

Mon, 08 Jun 2026 16:32:00 +0800

对应到目录

Z:\android\aml\s905x5\aml-s905x5-androidu-v2\bootable\recovery\recovery_ui\ui.cpp

对应代码

这里在对返回的按键做判定，判定之后根据需求返回信号

RecoveryUI::KeyAction RecoveryUI::CheckKey(int key, bool is_long_press) 
{
    ...
    //这是目前reset键的判定，这个if判定成功说明按下了reset，返回了TOGGLE
    if ((key == KEY_VOLUMEUP || key == KEY_UP) && IsKeyPressed(KEY_POWER)) 
    {
      return TOGGLE;
    }
    ...
}

在这里对返回的信号进行处理

原有的逻辑是现实/关闭UI文字，现在修改为移动索引，由于之前索引的移动是按下KEY_DOWN，所以可以直接复用逻辑，直接发送KEY_DOWN即可。另外还需要实现一个长按3s确认的功能。所以在接收到这个信号的时候进行一次判定如果是长按到来的信号，那么就走KEY_ENTER逻辑，否则就走KEY_DOWN逻辑

void RecoveryUI::ProcessKey(int key_code, int updown) 
{
    ...
    case RecoveryUI::TOGGLE:
        ShowText(!IsTextVisible());
        break;
    ...
}

void RecoveryUI::ProcessKey(int key_code, int updown) 
{
    ...
    case RecoveryUI::TOGGLE:
        ShowText(true);
        if (long_press) 
        {
            EnqueueKey(KEY_ENTER);  // 长按确认
        } 
    	else
        {
            EnqueueKey(KEY_DOWN);   // 短按下移
        }
        break;
    ...
}

另外对应到长按的逻辑在

void RecoveryUI::TimeKey(int key_code, int count) 
{
  ...
  std::this_thread::sleep_for(750ms);  // 750 ms == "long"
  ...
}