修改framework后如何编译、生效!生效!

被framework生效问题困了一天, 一定要记下来。试了网上各种答案,得到的结果都没生效。最终还是从同事那里得到的一份答案,还是同事靠谱啊。一、framework编译方法一般修改framework层的内容分为两种,一种是res,一种是源代码。前者只需要在其目录下,通过mm的方式即可将framewo

被framework生效问题困了一天, 一定要记下来。试了网上各种答案,得到的结果都没生效。最终还是从同事那里得到的一份答案,还是同事靠谱啊。

一、framework编译方法

一般修改framework层的内容分为两种,一种是res,一种是源代码前者只需要在其目录下,通过mm的方式即可将framework-res.apk编译出来,并且通过将其push到手机/system/framework/目录下,可即时生效。后者则有一箩筐要说。

遇到了修改res下的内容,生成framework-res.apk后推到手机里面后,出现无法开机、资源无法找到的问题。困惑了很久,后来慢慢意识到可能是当前手机的系统版本的原因。手机当前的系统为客户分支系统,而当前的framework-res.apk编译自master分支,客户分支当然有很多master分支没有的东西,所以推送到客户分支所编译出来的系统之后,出现了资源无法找到等奇怪的错误。正确的姿势是将当前的手机系统,刷成master分支所编译出来的系统,然后再进行操作。这个坑靠着自己的直(xia)觉(meng)怕了出来。

1.使用m命令编译framework只有在系统初次编译后第一次使用有效,之后编译会失败,需使用make命令。

2.编译命令及解释

编译指令 解释
m 在源码树的根目录执行编译
mm 编译当前路径下所有模块,但不包含依赖
mmm [module_path] 编译指定路径下所有模块,但不包含依赖
mma 编译当前路径下所有模块,且包含依赖
mmma [module_path] 编译指定路径下所有模块,且包含依赖
make [module_name] 无参数,则表示编译整个Android代码

下面列举部分模块的编译指令:

模块 make命令 mmm命令
init make init mmm system/core/init
zygote make app_process mmm frameworks/base/cmds/app_process
system_server make services mmm frameworks/base/services
java framework make framework mmm frameworks/base
framework资源 make framework-res mmm frameworks/base/core/res
jni framework make libandroid_runtime mmm frameworks/base/core/jni
binder make libbinder mmm frameworks/native/libs/binder

·对于make命令,模块名称未确定时,到相应目录下Android.mk文件中查找 LOCAL_PACKAGE_NAME 值。

通过上面的方法,可以编译成功得到framework.jar文件,但是将其push到/system/framework/后,则不一定会生效。

二、如何让它生效?

一般网上看到的做法是这样:

方法一:

将编译所生成的framework.jar推送到手机相应的位置,重启,看是否生效。如果没有生效,则继续删除/system/framework/arm目录和/system/framework/arm64目录中的boot.artboot.oat删除掉,之后重启机器。

如果这样操作后还是不生效该怎么办?

方法二:

在源代码的根目录,初始化好环境之后,在源代码的根目录下使用make snod,重新打包生成system.img,然后通过fastboot flash system %src_dir%\system.img,将新生成的system.img刷入手机,然后重启。

很遗憾,我还是没有生效。我把上面两者结合起来还是没有生效。。

方法三:

较为花式,请慎重服用。但这种近乎重新刷机的做法,感觉一定会生效

修改好了framework里面的东西之后,全局编译一次,然后将编译得到的结果刷入手机。

注意事项:

  • 如果在修改framework之前就已经进行过全局编译操作,那么在修改后,再进行全局编译,速度则非常快。
  • 如果在修改之后,还进行了git pull操作拉取了其他人对代码的修改,那么此次全局编译的速度就未知,不过基本上很慢。

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd