learnframework的博客

这里说的是一般并不是绝对，其实本质就是只要各个版本之间设备上抓取的Winscope的数格式差异不大可以兼容就可以，但是一般aosp13以后几个版本这块数据格式都有修改，所以13版本Winscope不支持抓取展示14，15设备版本数据。因为Winscope这个网页软件肯定是会考虑老版本兼容的功能，所以一般Winscope网页是新的，是可以兼容抓取老版本安卓设备的Winscope数据，比如aosp 15版本Winscope支持抓取展示aosp13设备的数据。3、Winscope的版本直接兼容原则是怎么样的？

针对Android Studio的版本不一样，对应LayoutInspector无法抓取布局解决方法也不一样，解决方法本质就是寻找一个合适替代插件Plugin工具，上面展示了两个版本Android Studio的插件安装方法，大家注意尽量大家用Android Studio的插件市场搜索方式下载，这样可以最大程度减少插件兼容问题，每个as版本插件不一定相互兼容。更多framework实战干货，请关注下面“千里马学框架”

经常做系统开发，经常会与Settings进行打交道，一般我们可能大部分去设置app里面找相关开关ui进行操作，但是经常有一些情况下一些新加的settings或者不常见的settings无法使用，这种可以直接使用命令进行调试就不要每次编写demo代码进行测试。本节在这个基础上进行额外增加一些实战工作提效命令，方便新手vip学员查阅，后续熟悉了其实也就不在需要查阅，大家一定要多在实际工作学习中多使用文章中命令，用这些命令来提升你的工作效率等。一般需要把cpp的如下屏蔽的define进行开放。

不过最简单方法当然是去网上搜人家现成开源的，当时我们就有参考github上一个开源的角标适配库，用它就可以实现大部分主流手机桌面的角标功能。有一个学员朋友就积极联系马哥，说他原来做第三方应用的，有负责过app在各个手机桌面显示角标功能，对这个角标适配深感麻烦，也非常希望google官方可以完全统一这一块的桌面角标功能各个手机厂商各自为战的情况。学员朋友也分享出来的了他以前适配各个手机厂商的桌面角标的相关详细接口调用，当时适配有10种手机的桌面角标功能。下面学员朋友开始分享app适配各个手机厂商的桌面角标。

角标是华为桌面提供给各应用一种展示未读信息的操作，以未读信息的数字合成一张图片并绘制到该应用图标的右上角。角标是华为桌面提供给各应用显示未读消息用的，会在应用图标右上角绘制一张消息条数的图标。

列出的面试题目大部分都是有答案的，答案可以vip群获取，有的是没有答案的，毕竟是去人家公司面试的，面试官也不是马哥，当然也就没有相关的答案，不过看到题目大家一般都可以有自己的答案，大家不确定的可以vip群中丢出来讨论。5、binder通信中不同进程的指向同一个Binder服务的客户端请求服务端时使用的handle是否是相等的呢?12、判断权限的时候，经常会传入一个uid，这个uid跟多用户的userId有什么联系吗？3、既然后黑屏冻屏的问题，你说说你分析的这个几个问题，是怎么分析的？

源码位置：组件IntentFirewall的作用IntentFirewall是Android框架中的一个组件，它可以根据XML文件中定义的规则来控制Intent的发送和接收。Intent是Android中用于组件间通信和启动的一种消息对象，它可以携带动作、数据、类别等信息。IntentFirewall可以根据Intent的属性和调用者的信息，决定是否允许或拒绝Intent的传递，从而增强系统的安全性和灵活性。

(CLEAR_VARS)：清除模块变量（如LOCAL_MODULE），需在每个模块开头使用。

经常在做系统开发需要使用一些命令来查看某个模块相关的信息，根据这些信息来清楚了解模块当前状态，比如常用的dumpsys activity，dumpsys SurfaceFlinger等命令，这些命令其实用多了自然就熟悉了。属于非常高频命令，主要用来展示当前设备上展示的画面，图层信息，一般用于调试，定位一些显示异常等疑难问题，属于做系统窗口和显示开发必须会的命令。这个命令内容太多，一般在想要展示所有信息时候使用，但是因为输出内容太多，一般会用他的子命令，更有目标性。1、某个apk是否安装，apk的安装路径。

不过在文件查找发现并没有我们新编译的目标没有加入PRODUCT_PACKAGES的文件，所以基本上我们就可以断定，aosp15相比aosp14就是在打包img时候，多了这个file_list.txt文件作为过滤依据，在打包img文件时候就是只会打包只有在file_list.txt文件中的，不在文件中也就不会打包。明显多了了个文件file_list.txt和file_list.txt.rsp，这里其实主要就是看file_list.txt文件既可以，可以看看它的内容。c.通过前置过滤机制保障输入目录纯净度。

对于代码调试，原来也只实战讲解过Java代码在Android Studio进行Debug，虽然Debug不适用于所有场景，但是在分析源码堆栈，调用关系时候还是非常有作用，所以学员朋友们也一直希望native 代码也有很方便的调试Debug方法，可以看到native代码的调用堆栈，这样也可以大大提高native代码的分析效率。这个报错暂时也没深入查找原因，重启模拟器设备后，重新调试就好了，大家也可以尝试重启。c++/c部分代码 ---->使用VSCode进行代码查看。在开启调试过程中发现偶尔会出现如下报错。

如果Android.bp和Android.mk同时存在情况下，什么也修改，那么会怎么样呢？明显报错already defined ，这个其实完全可以理解，因为Android.bp和Android.mk都同时哟定义目标linux_thread。所以Android.mk和Android.bp要同时存在的话，必要考虑解决重复定义的问题，即一套代码只能允许一个生效，要么是Android.mk生效，要么Android.bp生效。

面临上面要适配多个机型差异的问题，大家可能第一时间会想到用不同的代码分支不就行了么，但是大家注意如果用不同的代码分支同时意味着每个分支的代码你都需要进行维护，维护工作量极大，也就是经常可能修改了一个bug，做了一个新需求，你不得不同步一遍到多个分支，这样一旦机型多了，差异多了，你的维护成本会越来越多。情况2：代码编译依赖api或者库都有差异，即会有编译上的差别情况，那么这种就一定需要通过Android.mk,Android.bp中进行相关的条件判断才可以。案例1：使用不通过的依赖代码文件夹。

上面可以看出FileObserver本质都是调用的linux相关inotify接口，下面针对linux的inotify监听文件变化采用一个demo实战案例方便大家立即。1、自定义一个DataFileObserver继承FileObserver类，重写onEvent方法，一旦有文件相关变化时候就会回调这个方法。上面原理主要方法也有注释，这里可以看出ObserverThread主要还是一个线程类，主要核心业务方法都是调用到了native层面。在我们构造对应的FileObserver最后会调用到下面。

最开始，Ninja 是用于Chromium 浏览器中，Android 在7.0 中也引入了Ninja，因为随着Android系统和应用程序的增长，这种构建方式变得越来越慢，尤其是在大型项目中。为了解决这个问题，Google开始引入新的构建系统来提高编译速度和效率。Ninja是一个小型的、专注于速度的构建系统，最初由Google的程序员Chris Manson开发，最初用于加速Chrome浏览器的构建过程。Ninja的设计思路简化构建过程，通过精确指定输入和输出关系，实现快速增量构建。

定位与作用‌：Android.bp 是 Android 构建系统（Soong）的核心配置文件，用于定义模块的构建规则及依赖关系。它替代了传统的 Android.mk 文件，语法类似 JSON，但更简洁高效，支持模块化管理‌。发展历程‌：从 Android 7.0 开始引入，Android 8.0 后成为默认配置‌，基于 Ninja 构建框架，通过 Blueprint 解析，最终生成 Ninja 文件执行编译‌。

虽然AI无法完美满足你的实战需求代码，但是AI确实可以给你生成一个基本上可以用的成品代码，这个已经最少帮你节省了%70以上时间了，万事开头难，AI都帮助你开好了头，也帮你实现了一个基本可用的代码，你只需要在这个基础上改善完善他的功能，修复一些bug既可以，所以AI完全替代程序员这个事情是不太存在的，但是AI可以大大提升我们每个程序员的开发效率，让AI做出一些基本可用的模块类工作，节省我们大量的时间成本，我们程序员注意力集中在更高难度的一些AI无法实现需求和bug上。下面介绍2种常见方案来解决该痛点。

针对上面的问题，大家第一反应可能会说，既然eng版本没有问题，那么是否可以考虑编译一个整体eng的包不就行了？这种方法其实有条件情况下确实是一个最省事方法，但是很多时候出版本的不一定是自己，大家可能都是取公司编译好的版本用，然后修改自己模块push进去就行，所以很多时候不一定有完全eng的大版本可以使用。因为我们都是使用模拟器居多，模拟器编译的版本一般都是eng版本，所以没有这个同学问题，针对这样一类问题一般都是可能和自己的手机设备版本类型有关系，这个有问题版本确定是一个userdebug版本。

原理：因为breakfast，brunch其实属于lineage os自定义的函数帮助我们包装了一些操作而已，本身aosp是没有的，lineage os本质还是基于aosp的，所以自然aosp的所有编译命令也可以正常使用。1、物理解决方法，直接增加内存条，把内存变成64G，这种方式可能最简单啥也不需要改变，不过很多同学可能也有条件限制不一定可以，比如内存插槽不够，或者是内存条贵。2、增加swap虚拟内存，这种方法也是可以的，但是也需要消耗相关的硬盘空间等，需要重新扩展swap。

这个MyTaskOrganizer主要就是在构造时候有调用registerTaskListener，这个最后会调用到TaskOrganizer自带的registerOrganizer方法中去。其实从修改可以看出来，只是简单的构造了一个MyTaskOrganizer就会导致桌面Task无法显示，整个复现过程其实都属于程序员正常写代码行为，但是就是出现了个Task不显示问题。上面现象可以看到明显系统启动后桌面已经不显示了，那么就是针对这样一个桌面不显示问题作为学员作业布置给大家来进行探索。

整体非常非常简单，只需要调用add_sysprop_change_callback既可以，参数就是callback方法。2、prop变化回调部分，native其实本质就是放入了一个方法指针既可以，有prop变化通知后，会执行传递进来的方法。1、无论java还是native，通知prop变化其实都是通过跨进程通讯调用SYSPROPS_TRANSACTION。可以看到确实有相关的，不过这里会有连续两次回调打印，哈哈，这个你知道为啥吗？可以看到这里有调native_add_change_callback方法。

这里先来一个实战案例给大家展示一下具体如何对prop的值的进行监听变化及通知变化。1、监听方法/*** changes.* @hide*/这里监听比较简单，只需要添加一个callback既可以，也可以看出这里并没办法和settings那样针对某一个值进行监听，这里相当于是只要有prop变化通知发出，就会收到回调。2、通知prop变化的相关方法2.1 ActivityManager中的notifySystemPropertiesChanged方法/*** @hide*/@TestApi。

因为这种低内存问题本身就不属于一种功能操作类型的问题，属于一种系统当前可使用的内存少导致的问题，所以分析这类lmk低内存被杀的情况迫切需要一种可以帮助我们复现系统低内存的工具，今天马哥就给大家介绍一个内存压力工具mem-pressure详细使用和源码剖析。系统的mem-pressure并不是自带集成的，需要集成这个mem-pressure工具是需要自己进行额外编译的，所以要先进行编译mem-pressure的bin文件后再使用。3、子进程内存达到极限被杀了后会打印出申请的内存值。1、不断创建新的子进程。

大家明显可以看到这里的IDisplayManager.aidl文件被缩减成了只有两个方法，其实这个IDisplayManager.aidl文件属于原生系统的阉割版本，但是因为我们的需求就是获取的getDisplayIds，DisplayInfo.aidl是因为第一个接口getDisplayInfo需要的一个依赖，所以这个阉割的aidl也是完全可以满足的。缺点：需要针对每个跨进程的接口进行详细的细分，特别是组装和拆装parcel对象，这个每个接口都不一样，而且也比较容易出错。上一篇文章已经分享了相关的方案。

因为跨进程通讯本质上都是需要通过native端，虽然服务端或者客户端是java端，那都是先经过了native端再jni调用到java的，所以完全是可以实现客户端和服务端不要求两个都属于native或者java，完全可以native和java互通。代码1处的intTRANSACTION_getDisplayIds=2，注意这里的2就是从aidl对应的java文件中获得的，所有这个就是为啥要一定要找一个aidl文件生成的参考代码。，相信大家只要实战过马哥跨进程通讯课程肯定就对这个题目有自己的思路和方案。

方案1、直接拿到aidl文件后，使用最aidl命令来手动生成对应的java，或者c++等代码，这种方式优点就是简单方便直接，只要有aidl文件既可以，但是因为系统的aidl文件可能依赖很多系统类和代码，所以这里针对系统的复杂aidl文件手动生成可能就不合适了，较为麻烦。上面发现根本找不到IDisplayManager.java文件，只能找到一堆的IDisplayManager.aidl.d文件，这个不是我们想要的，那么该怎么处理才可以有马哥上面的IDisplayManager.java。

正确解答其实在ActivityManagerService类中本身有对这个LSP等进行解释，其实指的是锁的范围。学员疑问在正常情况下Splash窗口都是有Icon的，这里明显没有看到有Icon，只看到一个背景图，这个是为啥？3、学员询问分屏过程中请问到底有没有Splash Screen的画面展示，看到有图层，但是没有看到有Icon。对相关的android.iml进行了相关的修改，把sourceFolder放到最顶部了。正常打开App时候，展示的SplashScreenView的相关打印。

总体有以下几种情况1、认为做app门槛低，做的人太多，失业风险大，fw竞争力强，门槛较高，公司裁员时候fw开发者被猎头抢着要，app开发者有几年找不到工作2、大学社团就自带兴趣学习fw，因为自己对app开发只是画界面没意思，想要探索整个系统触摸3、校招进入小企业后发现做定制开发，技术太浅了，想要提高自己fw技术困难1：完全自学网络上一些零散fw技术blog，没办法成为完整模块知识体系，花了好多时间blog自学啥也没学会。

相信每个成功上岸framework工程师岗位的学员和粉丝们都有自己的一套独特学习方法，每个人的方法可能各不相同，所以举行一次社群学习方便大家一起交流framework的快速学习和成长方法相关经验分享，也许人家的好方法你也可以尝试一下是否也适合你，相互交流学习经验一起更加高效的找到适合自己最快的framework学习方法。一个人学习某个知识可能认知和理解都会比较有限，一群志同道合的人在一起学习讨论某一个知识，分享各自的理解，观点和成果，这样可以大大扩宽知识面，提高学习效率等。对题目有自己的思考和方案思路。

一旦这类偶现问题频繁出现会给造成很差的用户体验，但是这类问题又是偶现的，对于测试或者开发来说都是基本上束手无策，测试不知道这类偶现问题什么时候出现，无法抓取设备对应有效分析现场资料，开发无法得到偶现问题的资料，也无法进行有效的分析。‌社群学习‌是指一群有共同学习目标和兴趣的人，通过线上或线下的形式，进行知识分享、资源互助和共同进步的组织。一个人学习某个知识可能认知和理解都会比较有限，一群志同道合的人在一起学习讨论某一个知识，分享各自的理解，观点和成果，这样可以大大扩宽知识面，提高学习效率等。

心里焦虑加大了，需要调节好平常心面对创业以来最大感受就是“创业艰难”,原本预想的很美好，终于可以有勇气为了理想和兴趣奋斗了，一定是每天满怀激情的干。实际情况是：当自己的兴趣与谋生的收入挂钩时候，一切变得不那么理想和美好。每天还是会有担心自己课程的销售情况，必然就会有焦虑，这种心态和上班兼职搞完全不是一回事。所以心态上确实是相比以前有焦虑一些,这个部分做的不够好。时间不够用创业初期，也没有很多资金搞团队，大部分工作都落到我的头上，比如一些售前咨询，课程研发录制，答疑服务等。

大家都知道服务端执行一般是onTransact开始，这里面也可以看到有了相关的trace打印到systrace，但是实际上我们并没有看到有相关的trace有打印。代码中也可以看出线索，这里的Trace打印输出的tag是Trace.TRACE_TAG_AIDL，要这个可以打印出来那么必须要Trace.TRACE_TAG_AIDL是开放的状态。这里的systrace打印跨进程的方法，不是针对所有接口都有哈，一般针对aidl文件实现的接口才有，因为都是会通过aidl工具进行编译时候植入相关trace。

ps：这里最重要就是keytool使用的要和android studio对应的jre目录的一致，一定要注意这里的keytool要注意它对应的java版本，如果java版本不对会导致生成的platform.jks无法被android studio编译，会不断报错Invalid keystore format。经常做framework开发或者系统应用开发时候，都会有一个很熟悉的名词“系统签名”，因为有了系统签名才可以有比普通第三方应用更高的权限，很多核心函数才可以进行调用成功等。开发效率的提高，或者本身代码。

meta-data其实无论在普通app开发还是系统开发过程中都是非常重要的，可以在app的AndroidManifest中配置相关的自定义数据，然后在代码中可以获取到AndroidManifest配置的meta-data数据，不仅仅app进程自己可以获取到这个数据，其他进程也可以获取到这个meta-data数据，这样对于系统识别一些Activity特性时候就提供了重要的依据。

文章中也说明在aosp15如果直接使用编译好的离线html是有问题的，无法正常显示抓取的Winscope文件。针对这样一个问题对于有些同学来说还是很不友好，因为很可能他们不想搭建node相关的环境，那么针对 aosp15上Winscope离线的html是否真的不可以使用呢？不过我们可能不关心原因，因为这块毕竟属于前端的知识，我们更关心应该怎么解决。

这里面就有这个from uid 10108，即看到uid = 10108，但是这个uid = 10108到底是谁呢？u0_a108 分为两部分，前面u0中的0代表就是userId = 0这个用户，除了0设备还有可能有其他用户比如常见的分身10，后面a108的108就是代表基于10000的累积是108，预先判断uid的值大小，一般普通的apk程序等，uid的值一般大于10000，这种uid大于10000情况确定可以使用直接计算法。那么就用这个108前面加上字符a，即a108去ps -A中进行搜索。

近来有学员朋友询问到了一个他做性能优化时候的一个疑问，那就是他不知道自己的手机设备上的一个cpu情况，他想要知道目前的平台哪些是cpu的大核哪些是cpu的小核，问马哥有没有啥命令或者方法进行查看，这样就可以不需要通过问其同事了，每次问都容易忘记，而且每个平台也不一样。一般平时常说的cpu大小核情况，其实说的是cpu一般情况下都是有多个核心的，和我们电脑上cpu是一个情况，但是多核心为了综合性能和功耗上都兼顾，就不能说所有核心都是大核或者小核，一般都是大小核都是共同存在的。cpu的4-7属于大核。

上面就是程序员在工作过程中遇到“边缘化”的一些情况及如何面对解决“边缘化”问题，总结就是：面对“边缘化”任何时候都不要自暴自弃，一定要积极面对工作，因为你其实为自己工作，你提升自己工作业务能力才是核心，让自己在市场变得更加值钱，自身能力和修为提高了，你才可以不需要担心焦虑在当前公司被“边缘化”。

可以看到这里确实在编译InputDispatcher.cpp:356时候发现引入ld不到libutilscallstack库，所以导致无法找到符号表报错，但是明明我们确实cpp编译的bp中加入了相关的libutilscallstack，那这种应该怎么解决呢？注意这里如果模拟器整编还是报错，只能回退再编译，但是可以保存单编译libgui.so覆盖回退的，然后再触发打包既可以。这些编译都不是在编译libgui.so时候报错的，都是编译media相关库才报错的，也就是说其实单独编译libgui是可以成功的。

这个也就是为啥会报错的原因，那么清楚了原来libstagefright_bufferqueue_helper,libstagefright_bufferqueue_helper_novndk对这个有依赖，那么是否可以直接在这个bp加入 libutilscallstack呢？针对调试和分析某个模块的源码时候，经常需要对某个方法进行堆栈的打印，java相关的代码都没啥问题，大家都可以很正常的打印出来，但是一些native的模块就不是那么顺利了。一看到这些报其实大家可能都一脸懵，不知道为啥会有这种错误。