system.img无法打包非PRODUCT_PACKAGES目标解析

Android编译系统分析五:system.img的生成过程 我们在完整编译android系统的时候,最终会生成几个重要的镜像文件,其中有system.img,userdata.img,ramdisk.img等。这篇文章的目的是分析system.img的生成过程。 回想下我们完整编译android系统时的动作,我们会在android源码顶级目录执行make命令,这样就会完整的编译android系统,我们没有传入任何参数(-jx等加快编译的除外),因为我们没有明确指定mak 阅读详情

背景:

针对上一篇文章给大家步骤的关于aosp15版本上system.img的打包已经和以前aosp14不一样的问题,这里再简单描述如下:
在这里插入图片描述但是在aosp15后,明显发现并不会打包整个system文件夹。
下面来探索这个到底是为啥?

线索追踪:

这里主要通过对比在out目录下对应的img的输出的中间目录
先看aosp14上同样的目录如下:

test@test:~/disk2/aosp14/out/target/product/emulator_x86_64/obj/PACKAGING/systemimage_intermediates$ ls -l
total 991824
-rw-rw-r-- 1 test test       2960 Apr 24 12:36 system_image_info.txt
-rw-rw-r-- 1 test test 1083002880 Apr 24 12:36 system.img

再看aosp15的情况如下:

test@test:~/aosp15/out/target/product/emu64x/obj/PACKAGING/system_intermediates$ ll
total 791680
drwxrwxr-x  2 test test      4096 Apr 24 22:34 ./
drwxrwxr-x 25 test test      4096 Apr 24 11:14 ../
-rw-rw-r--  1 test test     62288 Apr 24 11:29 file_list.txt
-rw-rw-r--  1 test test    258910 Apr 24 11:14 file_list.txt.rsp
-rw-rw-r--  1 test test       992 Apr 24 22:33 system_image_info.txt
-rw-rw-r--  1 test test 877621248 Apr 24 22:35 system.img

明显多了了个文件file_list.txt和file_list.txt.rsp,这里其实主要就是看file_list.txt文件既可以,可以看看它的内容

在这里插入图片描述不过在文件查找发现并没有我们新编译的目标没有加入PRODUCT_PACKAGES的文件,所以基本上我们就可以断定,aosp15相比aosp14就是在打包img时候,多了这个file_list.txt文件作为过滤依据,在打包img文件时候就是只会打包只有在file_list.txt文件中的,不在文件中也就不会打包。

至于是否使我们猜想的结论可以还需要更多验证,和需要相关build模块的git log来验证,看看这个修改的目的。

追查为什么要加入file_list.txt

这里可以通过在aosp15的代码中进行相关的grep file_list字符,因为涉及是编译模式变化,当然要到build目录进行grep,结果如下:
在这里插入图片描述
然后通过git blame看看这个提交记,然后git show看看相关提交详情

test@test:~/aosp15/build/make/core$ git show 152cdfab7c2
commit 152cdfab7c2a02a64b24a706566183d863db7a38
Author: Cole Faust <colefaust@google.com>
Date:   Wed Jul 26 14:33:51 2023 -0700

    Clean staging dirs in build_image.py
    
    build_image.py now accepts a --input-directory-filter-file argument
    that contains a list of files to consider from the input directory.
    A new, temporary input directory will be created, and only the
    considered files will be copied to it.
    
    This removes most of the need for `m installclean`, as old files or
    files built manually will no longer end up on the partition.
    
    Bug: 205632228
    Test: Presubmits
    Change-Id: I07e0bf8e840abf0b51a2fdf67b758905fb3c5b5b

diff --git a/Changes.md b/Changes.md
index 6836528762..2616117d7a 100644
--- a/Changes.md
+++ b/Changes.md
@@ -1,4 +1,15 @@
-# Build System Changes for Android.mk Writers
+# Build System Changes for Android.mk/Android.bp Writers
+
+## Partitions are no longer affected by previous builds
+
+Partition builds used to include everything in their staging directories, and building an
+individual module will install it to the staging directory. Thus, previously, `m mymodule` followed
+by `m` would cause `mymodule` to be presinstalled on the device, even if it wasn't listed in
+`PRODUCT_PACKAGES`.
+
+This behavior has been changed, and now the partition images only include what they'd have if you
+did a clean build. This behavior can be disabled by setting the
+`BUILD_BROKEN_INCORRECT_PARTITION_IMAGES` environment variable or board config variable.
 
 ## Perform validation of Soong plugins

这里大概提交中可以看出:

build_image.py脚本新增的–input-directory-filter-file参数实现了输入目录文件过滤功能,其核心作用与实现逻辑可归纳为
a.通过指定包含文件列表的过滤文件,脚本会自动创建临时输入目录,仅复制列表中明确指定的文件到新目录

b.有效解决了旧版本构建残留文件或手动生成文件意外混入分区的问题

c.通过前置过滤机制保障输入目录纯净度

修改方案:

这里修改方案可以如下两种:

1、正常把目标放入到PRODUCT_PACKAGES,这种就啥事情也没有,本身目标也是系统img的一员

2、不想放入到PRODUCT_PACKAGES,还是想要可以打包到img
这种临时修改方案可以如下:
步骤一:修改out目录下的的file_list文件

修改 out/target/product/emu64x/obj/PACKAGING/system_intermediates/file_list.txt文件,如下在这里插入图片描述

然后再老方法,触发系统重新打包编译,运行模拟器看看现象如下:
在这里插入图片描述

更多framework实战vip独享干货,请关注下面“千里马学框架”

Android 14 AOSP编译实战:Ubuntu环境搭建、源码下载与系统构建全流程 操作系统构建是现代软件开发中的核心环节,它涉及将源代码转化为可运行系统的完整流程。其原理基于构建系统(如AOSP的Soong/Ninja)对依赖关系的解析与并行编译,技术价值在于提供了从底层理解系统运作、深度定制和性能优化的能力。这一技术广泛应用于系统开发、ROM定制和嵌入式设备等领域。本文聚焦于Android 14系统构建,详细解析在Ubuntu环境下完成AOSP源码下载、环境配置、编译构建到运行调试的全链路实践,其中涉及**源码同步**的网络优化策略与**增量编译**的效率提升技巧,为开发者提供从零到一 阅读详情

相关推荐

Android源码编译与烧写实战:从环境搭建到设备部署全流程解析

在嵌入式开发和系统定制领域,编译与烧写是连接软件源码与硬件设备的核心技术环节。编译过程基于构建系统(如AOSP的Soong/Blueprint)将源代码转换为可在特定硬件上执行的二进制镜像,其原理涉及交叉编译工具链、模块依赖解析和镜像打包。这一技术的价值在于实现对操作系统底层的深度控制与定制,例如优化启动流程、预置系统应用或适配专属硬件驱动。典型的应用场景包括为物联网设备、车载娱乐系统或定制化安卓设备打造专属系统镜像。其中,fastboot协议作为通用的刷机工具,通过USB连接在Bootloader模式下完

weixin_33797791的博客 393

Android 镜像文件生成流程

Android编译基本流程 (1)source  build/envsetup.sh (2)lunch xxx  // lunch   之后 选择xxx  index (3)make  -j16                   envsetup.sh 主要是设置编译时的一些系统环境变量,加载 vendor,device 目录(及子目录)下所有vendorsetup.sh ,接着lunc

Tony的专栏 1万+

RK3588安卓系统开机自启动实战:从原理到系统应用配置全解析

在嵌入式系统与物联网设备开发中,开机自启动是确保设备上电后核心服务或界面能自动运行的基础需求,尤其在基于安卓系统的智能终端上。其实现原理涉及对安卓系统启动流程的深度理解,包括从Bootloader到Launcher的完整链条,以及如何在合适的环节插入自启动逻辑。从技术价值看,可靠的自启动机制直接关系到设备的可用性和用户体验,是工业平板、自助终端等“上电即用”场景的关键保障。常见的实现方案包括监听系统广播、配置系统服务以及利用平台特性等,其中将应用预置为系统特权应用并监听BOOT_COMPLETED广播的组合

anheku1562的博客 416

为什么安卓aosp15打包system.img中无法包含没有在PRODUCT_PACKAGES定义的目标--学员作业

简单说就是为了方便,只会make xxx目标,,一般都会在system/bin目录或者system/app目录有对应程序,然后触发一下系统打包system.img,emulator启动后就可以在设备上看到编译的目标。但是经常我们有时候为了方便,自己写的一些简单的测试native,apk,可能只会进行的Module进行编译,不会把Moudle加入到PRODUCT_PACKAGES进行预制。接下来要触发系统打包system.img,一般这里采用touch一个系统一定会编译的cpp文件,然后进行make。

learnframework的博客 584

Android命令行工具深度解析:sdkmanager、adb与fastboot工程实践

Android命令行工具是支撑移动开发自动化与底层调试的核心基础设施,其本质是一套遵循POSIX标准、与IDE解耦的SDK控制中枢。它基于标准化协议实现环境构建(sdkmanager)、设备通信(adb)和固件操作(fastboot)三层能力,具备确定性、可脚本化与跨平台特性。在CI/CD流水线、Docker容器、无GUI服务器等工程场景中,该工具链直接决定构建稳定性、设备连接可靠性及固件刷写安全性。尤其在多环境部署、macOS Ventura适配、Windows静默安装及离线企业级交付中,正确配置ANDR

weixin_34245749的博客 366

Ubuntu 16.04构建Android ROM:稳定编译环境与AOSP工程实践

Android ROM构建本质上是跨工具链、跨ABI、跨生命周期的系统级工程实践。其核心原理在于编译环境与AOSP源码分支(如Android 7.1–9.0)的二进制兼容性匹配,技术价值体现在构建确定性、复现性与产线稳定性。典型应用场景包括LineageOS定制、厂商闭源Blob集成及老旧设备固件维护。在GCC 5.4、OpenJDK 8u292、Python 2.7.12等经典组合下,Ubuntu 16.04成为验证Android Nougat至Pie版本的‘编译标尺’;而vendor blob集成与ja

cishan3804的博客 553

Android framework 编译常见错误

常见错误: 1)  添加系统API或者修改@hide的API后,需要执行      make update-api,然后再make 2) 修改公共api后,需要      make update-api      比较framework/base/api 下的current.xml跟原始x.xml(比如2.2为8.xml 2.3.3为10.xml),同时修

shengyakun的专栏 6235

在TI开发板上移植Android Automotive OS:从HAL到CTS的完整实践指南

Android Automotive OS是专为汽车座舱设计的操作系统,它通过硬件抽象层(HAL)实现应用与硬件的解耦,为车载信息娱乐系统(IVI)提供了标准化的软件框架。其核心价值在于构建一个安全、可靠且可扩展的智能座舱平台,广泛应用于车载中控、仪表盘及乘客娱乐系统。本文聚焦于如何在德州仪器(TI)的AM57xx/AM65x开发板上进行Android Automotive移植,深入解析了Vehicle HAL的实现、系统构建配置,并详细介绍了兼容性测试套件(CTS)与供应商测试套件(VTS)的实战流程,为

weixin_34175509的博客 510

android custom.img 编译生成,Android:编译系统总结

总结一下android的编译系统一.Android的编译脚本在哪里?在build/core目录下,使用的是makefile的方式。入口是main.mk。一般我们执行make去编译。在根目录下可以看到一个Makefile,这个就是入口了。image.png看一下编译的目标:image.png第一个定义的PHONY就是目标了。所以目标是droidTARGET_BUILD_TYPE和TARGET_BUI...

weixin_36189159的博客 1642

Android虚拟化框架AVF:基于pKVM的硬件级安全隔离实践

硬件虚拟化技术通过在单一物理硬件上创建多个隔离的执行环境,实现了资源的高效利用与安全隔离。其核心原理是利用CPU的虚拟化扩展(如ARM的EL2异常等级)和内存管理单元(MMU)的第二阶段地址转换,在硬件层面为每个虚拟机构建独立的运行空间。这项技术的核心价值在于能够提供比传统操作系统级沙箱更强的安全边界,确保即使一个环境被攻破,其他环境仍能保持安全。在移动设备领域,这种强隔离能力对于保护数字钱包、生物特征识别、企业数据等高价值资产至关重要。Android虚拟化框架(AVF)正是基于ARM pKVM技术构建的标

ckkay800264的博客 423

AAC编解码器在实时通信中的性能对比与应用选择

本文深入分析了AAC编解码器在实时通信中的性能优化,重点对比了faac、faad2与fdk-aac三大开源方案在WebRTC场景下的表现。通过实测数据揭示其在延迟、音质和资源消耗等关键指标的差异,并提供场景化选型建议与调优技巧,帮助开发者提升实时音视频通信质量。

weixin_29210727的博客 389

android编译 预装apk,Android Framework开发 - 向系统中添加预装App

文章目录[x]1:模块编译2:拷贝Apk并配置Android.mk3:编译并打包在上一篇文章中,介绍了Android Framework开发的一些基础知识和调试技巧。在本文中,将介绍如何在系统中植入预装App,本教程以及后面一系列教程将以Android 10进行开发编译。模块编译模块编译的前提是源码要全部编译完成一次,后面对代码修改,就可以通过编译模块的方式,从而提高开发的效率。如下是模块编译的命...

weixin_36254564的博客 1263

AI大模型应用性能核心指标:TTFT 与 TPOT 详解

这两个指标专门衡量大模型流式响应性能,是评估用户体验的关键指标。· 是什么:从请求到第一个输出的等待时间· 为什么重要:决定用户的第一印象和响应感知· 优化方向:模型加载、预处理、冷启动优化· 行业标准:最好<500ms,可接受<1.5s· 是什么:每个输出token的平均生成时间· 为什么重要:决定流式输出的流畅度和总完成时间· 优化方向:推理引擎、内存带宽、批处理优化· 行业标准:最好<50ms/token,可接受<100ms/token在Dify/大模型应用中的意义。

lovehu6686的博客 3967

Android学习25--SDK3(TODO)

本文主要总结了Android AOSP和高通SDK的开发重点目录结构。AOSP方面,核心关注frameworks、system、hardware、kernel等目录,涉及BSP开发、系统服务修改和内置App开发。高通SDK部分,重点在vendor/qcom目录下的HAL/驱动代码,以及QSSI(通用系统镜像)和Vendor(硬件相关)的分离编译架构。作者反思了之前未及时总结高通开发经验的遗憾,建议开发者重点关注芯片厂商提供的闭源代码和硬件抽象层实现。文章对比了标准AOSP和高通扩展的目录差异,为Androi

fanged的专栏 509

易灵思FPGA-软件Efinity和Modelsim联仿设置

文章目录前言一、modelsim破解过程二、使用步骤1.引入库2.读入数据总结欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能,丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 前言 提示:这里可以添加本文要记录的大概内容: 例如:随着人工智

qq_35221855的博客 5362

手把手教你双目测距理论及生成视差图,深度图,点云图像

Stereo Vision, 也叫双目立体视觉,它的研究可以帮助我们更好的理解人类的双眼是如何进行深度感知的。双目视觉在许多领域得到了应用,例如城市三维重建、3D模型构建(如kinect fusion)、视角合成、3D跟踪、机器人导航(自动驾驶)、人类运动捕捉(Microsoft Kinect)等等。双目测距也属于双目立体视觉的一个应用领域,双目测距的基本原理主要是三角测量原理,即通过视差来判定物体的远近。

qq_53545309的博客 2280

项目实训——个人博客:基于RISC-V的OpenHarmony 6.1移植实战 (三):构建树级联解析异常与交叉编译链缺陷修复

针对 OpenHarmony 6.1 操作系统在基于进迭时空 K1 芯片的开发板上的全量编译部署问题,本文深入分析了底层构建系统(Build System)在执行阶段的异常状态。内容涵盖 GN(Generate Ninja)配置生成阶段的依赖树级联解析失败机制,以及 Ninja 编译阶段跨平台交叉编译器预编译包内关键环境依赖缺失的底层机理。本文结合软件工程中的模块化解耦原理与编译原理,提出并验证了一套架构级依赖裁剪与宿主环境映射的修复方案,并记录了系统固件的首次物理烧录与 U-Boot 引导过程。

si_xiaosheng的博客 254

《QGIS快速入门与应用基础》108:CGCS2000对应的投影坐标系

本文详细解析了CGCS2000地理坐标系对应的各类投影坐标系,包括高斯-克吕格3°带/6°带、UTM、地方独立投影和Web墨卡托投影。文章系统阐述了各投影类型的分带规则、参数设置、精度特性及适用场景,并提供了EPSG编码对照表和QGIS操作指南。通过"基准+投影"的绑定机制,这些投影坐标系实现了平面坐标与经纬度的精准转换,满足从大比例尺工程测量到Web地图服务等不同应用需求。内容涵盖投影原理、坐标格式、变形控制等关键技术要点,为GIS开发者和测绘人员提供了实用的参考信息。

LuckyHanMo的博客 541

Android 7系统编译与刷机(一)源码环境搭建与完整编译流程

Android 7系统编译与刷机(一):源码环境搭建与完整编译流程 本文是Android 7系统编译与刷机系列的首篇,重点讲解源码环境搭建与完整编译流程。主要内容包括: 学习编译流程的重要性:解决日常开发中全编耗时、镜像打包机制不明、分区表配置等实际问题。 编译环境准备: 硬件要求:150GB硬盘空间,16GB内存(解决jack-server OOM问题) 操作系统:推荐Ubuntu 14.04/16.04 JDK版本:必须使用OpenJDK 8 源码下载: 使用清华镜像站加速下载 Repo工具解析及多仓库

AfinalStone的专栏 252

【GlobalMapper精品教程】084:tif(tfw)、jpg(jgw)、png(pgw)的区别与联系

摘要:本文介绍了TFW、JGW、PGW等地理参考文件的基本原理和应用。这些文件通过简单的文本格式存储栅格图像的地理坐标信息,适用于平面坐标系下的GIS数据处理。文章详细说明了文件各行的含义,并提供了在ArcGIS和Globalmapper中生成这些文件的具体操作步骤,包括导出TIFF、JPG、PNG格式时勾选生成对应坐标文件的选项。这些文件虽然简单易用,但仅适用于平面坐标系,且功能相对有限。配套视频教程提供了更详细的操作演示。

智慧空间实验室 2402

ICC2: place阶段的clock network delay

设置了set_clock_latency之后,即便没长tree,也会有反标值,显示为clock network delay(ideal)和设置的clock latency值,需要注意的是同时设置set_clock_latency和set_clock_latency -source,clock network delay(ideal)值是二者叠加的。我正在「拾陆楼」和朋友们讨论有趣的话题,你⼀起来吧?

m0_61544122的博客 317

02_代码编译、构建、烧录和测试

记录 OpenHarmony 6.1 RISC-V 源码同步、MUSEPaper2 全量构建、镜像打包、原始系统烧录、外设基线测试与工程验证方法。

学中干,干中学;尽人事,听天命。 124

基于STM32设计的水下水质检测装置(微信小程序)(205)

本项目设计了一款基于STM32微控制器为核心的水下水质检测设备,该设备具有高度集成化、智能化的特点,能够实时监测水深、温度、浊度及溶解性总固体(TDS)等关键水质参数,并通过4G网络将数据上传至腾讯云IOT物联网平台,实现远程监控和数据分析。同时,为了便于操作和移动观测,还配套开发了微信小程序,用户可通过微信小程序实时查看并控制设备的各项功能,如调整下潜深度等。

1252

Android编译系统详解(二)

++++++++++++++++++++++++++++++++++++++++++ 本文系本站原创,欢迎转载! 转载请注明出处: http://blog.csdn.net/mr_raptor/article/details/7540066 ++++++++++++++++++++++++++++++++++++++++++     Android编译系统详解(一):htt

索峰的个人专栏 360

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

i.MX 8 Android 14构建实战:从环境配置到镜像定制的完整指南

嵌入式系统开发中,构建定制化的Android平台是连接硬件与上层应用的关键环节。其核心原理在于将AOSP源码、硬件厂商提供的驱动与补丁,通过交叉编译工具链整合为可直接烧录的系统镜像。这一过程的技术价值在于实现对系统从引导程序到应用层的完全控制,从而满足工业平板、智能设备等场景对性能优化、外设驱动和多屏显示等特定需求。以NXP i.MX 8系列平台为例,构建流程涉及U-Boot、Linux内核与Android框架的协同编译,其中imx-make.sh脚本扮演了桥接标准AOSP构建与硬件特定编译的关键角色。通过

455

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

上一篇: 为什么安卓aosp15打包system.img中无法包含没有在PRODUCT_PACKAGES定义的目标--学员作业
下一篇: 干货笔记:安卓系统开发工程师必须掌握常用命令汇总(不断更新)
千里马学框架
博客等级 码龄6年 1万+粉丝 650原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

千里马学框架

帮助你了,就请我喝杯咖啡

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值