项目问题归档

S905Y5 平台 AHDR（Advanced HDR）真机验证调查报告 报告日期：2026-08-11 平台：Amlogic S905Y5（S7 平台，板级 qurra） 素材：Amlogic 交付 AHDR.zip（2025-07-17 打包） 验证目标：确认板载 AHDR 功能可用，并通过 sysfs 节点调节生效 1. 调查背景 为论证 S905Y5 对 Advanced HDR by Technicolor（即 SL-HDR1 / SMPTE ST 2094-40）的支持能力，已实施以下集成工作： 步骤 内容 状态 1 AHDR.zip 内 5 个补丁（prime_sl 驱动 / fb4ad875 UI 节点 / h264 SL-HDR 提取 / h265+h264 auxdata 修复 / cpq）打入源码库 ✅ 完成 2 平台迁移：原补丁平台表不含 S7，自行移植 6 处改动（dts 节点、平台表、寄存器分支、build.cfg=qurra） ✅ 完成 3 编译并烧录镜像 ✅ 完成 4 静态检查：/sys/module/aml_media/parameters/ 下 prime_sl_display_brightness、prime_sl_display_adaptation_tuning 节点存在 ✅ 通过 5 功能验证：播放视频过程中写入调参节点，观察画面/输出变化 ❌ 无任何作用 本报告回答两个问题： ...

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 签名机制（通俗笔记） 面向：刚接触 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 都有两类文件： ...

一、从实际案例出发：1G → 2G 为什么不需要改代码？ 1.1 实验现象 板子从 1G DDR 换到 2G DDR，软件未做任何改动，上电直接正常启动： # cat /proc/meminfo | head -3 MemTotal: 2036132 kB ← 2GB 全部识别 MemFree: 1901472 kB MemAvailable: 1938064 kB # cat /sys/class/aml_ddr/freq 504 MHz ← 频率不变 # dmesg | grep "Memory:" Memory: 1999064K/2097152K available Virtual kernel memory layout: memory : 0xffffffa640000000 - 0xffffffa6c0000000 (2048 MB) # cat /proc/iomem | head -1 00000000-7fffffff : System RAM ← 2GB 地址空间全覆盖 1.2 为什么可以不改？ 答案在于 Amlogic（以及多数现代嵌入式 SoC）的 DDR 初始化架构。整个 DDR 初始化流程分为两个阶段： ...

开机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 开机脚本编写指南 以 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 键弹出关机对话框 — 定位过程总结 背景 在 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 的行为。 ...

对应到目录 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" ... }