learnframework的博客

发起跨进程调用会执行到binder_transaction方法中，这里会创建对应的binder_transaction，而且会给binder_transaction进行相关的赋值，然后到目标进程的binder_thread_read进行使用。在目标进程binder_thread_read方法中，会读取上面的对sender_pid和sender_euid进行设置，返回到app层面。可以看到这里的赋值来源就是binder驱动中传递过来的sender_pid，sender_euid。

系统中即可以设置桌面壁纸，也可以设置锁屏壁纸，而且二者还可以长得不一样，各自设置各自壁纸，请问这块原理是什么？锁屏壁纸和桌面壁纸是如何区分的差异显示，是同一个Wallpaper的窗口显示不同的bitmap还是说根本就是不同的Wallpaper窗口？简单说他们原来解决办法是锁屏壁纸是作为锁屏界面的一个背景图片bitmap，和锁屏窗口的view是一体的，当然这个解决方案具体还得复现问题尝试验证，这个方案表面理论上看着可行。但有学员朋友又私下问到了，锁屏壁纸和桌面壁纸的相关差异区别原理是啥？

以前高斯模糊原理也分析过，知道是在SurfaceFlinger触摸绘制时候进行的高斯模糊，那么再来分析一下高斯模糊相关实现时候是否有相关区域设置参数，从而反推出相关接口。简单说学员就是想实现对状态栏等区域局部进行高斯模糊，以前方案是针对窗口layer所有进行模糊，那么是否可以实现窗口的局部高斯模糊呢？但是上面分享模糊都是针对整个窗口进行的，就是桌面窗口设置一下后面窗口进行模糊的标志位，然后针对桌面窗口后面的壁纸窗口进行整体模糊。那么接下来要去探索aosp原生系统是否有接口支持局部高斯模糊呢？

2、因为自定义壁纸本身就是继承WallpaperService重写一个壁纸服务，每个服务可以通过WallpaperService.Engine#getDisplayContext() 方法获取到自己在不同的屏幕，简单说就是WallpaperService有自己context，可以通过context获取到自己的Display，也就是多个屏幕会有多个WallpaperService而且Service中可以识别自己对应的display，这样就可以差异识别。明显发现主屏幕正常显示自定义壁纸，但是副屏显示为黑屏。

经常有vip学员朋友们在vip群里，或者私下问我一些开发中技术需求，技术困惑，难题等，一般马哥针对每个vip学员的问题都会认真看，一些和我们课程技术相关的，我都会及时和大家进行回答反馈。2、如果第1步确定Layer确实有，但是还看不见圆角，那么一般这种情况下主要还是显示区域范围的问题，简单说就是圆角确实有圆角，只不过圆角没有在显示区域范围内，圆角可能显示在裁剪区域范围外，这个情况其实在SurfaceFlinger课程的GPU合成讲解时候有讲过。

2、单手设置本质就是对上面所有FEATURE_ONE_HANDED的WindowContainer进行位置Y方向的偏移。1、收集所有的Feature为FEATURE_ONE_HANDED的WindowContainer，进行保存到集合。这里OneHandedTransitionAnimator又是由ofYOffset方法导致的构造。那么这里的mDisplayAreaTokenMap又是哪里设置的呢？那么看看这里的leash是哪里传递过来的。那么这里的mLeash又是哪来的呢？

3、对系统的display的图层会进行Mirror，创建出一个新的MirroRoot图层，下面挂载了系统层级结构的Mirror图层，名字一般会在后面加上“（Mirror）”字样，内容和源图层一样。而且这些图层是有本质上是Mirror了现有的图层，比如桌面和壁纸都显示在放大镜的区域，而且只有放大镜的区域桌面和壁纸是放大的，其他非放大镜区域就是正常显示，那么是如何实现这样呢？但是大家是否有一个很大疑问？2、放大镜功能开启后，会创建对应的Windowless窗口，而且这个窗口有对应的SurfaceView。

这仅适用于在调用 finish() 时，应用在前台中具有一项 activity，或在前台任务的返回栈中具有一项 activity 的情况。不过也可以看出这些代码中的额外一些条件，其实都不是普通第三方app可以的达到的条件，所以文档中也没有列出这些，文档主要还是列出第三方应用可以达到条件。那么这个问题应该如何解决呢？所以对于系统应用而言，如果想要后台启动，只需要在自己的apk中添加权限既可以，注意同时要有系统签名或其他条件。3、应用在“最近使用的应用”屏幕上现有任务的返回堆栈中具有 activity。

这个需求也像学员朋友群里的说的，属于做机顶盒相关的开发的常见需求，所以整体的作业需求的难度算一般，既然一般难度的需求，那么更需求各位学员朋友可以进行实战实现啦。上面主要对系统进行整编，然后安装apk（注意不要点击启动这个app），点击音量上按键，但是发现没有任何的反应，只有log输出，并没有Activity的跳转。–主要负责解析global_keys.xml中定义的keycode和对应的broadcast的component，方便后续处理时候有重要的依据。可以看到有我们mKeyMapping相关的数据。

近来vip群里学员朋友有问道一个需求，大概需求就是他们做TV的Framework开发，想要遥控器有一个新定义的儿童节目按键，想要实现这个按键按下后就跳转到儿童节目的Activity。3、需要考虑儿童节目app进程，接受到了按键事件后，需要考虑拉起Activity，注意这里有可能儿童节目app压根没有任何的可见窗口。1、针对按键事件的全局监听和处理，建议大家可以采用2种方案进行实现，这里的儿童按键，大家可以使用其他现有按键进行模拟既可以。1、按键部分，需要全局对事件进行监听，而且可以处理相关的响应逻辑。

相当于需要把CarLauncher如何显示TaskView这套流程代码理解清楚，然后把这块的业务整体进行移植到一个全新的系统app，然后这个新的系统app可以实现不依赖car相关东西也可以正常运行。上面的属于基于AAOS的CarLaucnher直接自带的功能，但是大家是否想过，如果没有CarLauncher情况下该如何实现这个Activity的嵌入功能呢？1、普通的手机Activity，有一个FrameLayout，专门用于装载TaskView。安卓设备为手机类型也可以phone类型的模拟器。

大家都可能为了提高开机启动速度，或者说不想让用户看到Fallbackhome画面也好，都会有想办法去除Fallbackhome的需求或者想法，但是大家需要注意的是android以前也是没有Fallbackhome的，也是指导出现了CE加密才出现的，本质上Fallbackhome就是作为系统还没解锁前作为launcher的Activity进行启动，不然系统啥Activity都无法启动的话，就会一直处于开机动画，无法进入系统。那么最后是否可以去除Fallbackhome呢？

的Fallbackhome本身好像没有干啥啊，它也只是等待检测设备解锁后启动Launcher，Fallbackhome本身自己又没有调用啥解锁，属于被动，所以普遍认为系统会自己解锁，解锁后自然会触发系统重新进行Launcher的启动。针对这个去除Fallbackhome去除后是否可以正常进入Launcher的问题，学员们也进行了激烈讨论，很多学员朋友都猜想肯定还是会进入Launcher的，只是可能时间会长一点，那么真实的情况是真的会吗？然后运行模拟器：emulator。aosp 15 编译模拟器。

明显可以看出当前的多屏情况下，壁纸都是展示的一张，无法实现对每个屏幕有单独壁纸的展示，但是在多屏情况下毕竟属于两个独立的屏幕，所以用户肯定会有想法让多屏展示有差异，这里的壁纸差异化的多屏展示就是很重要的一个需求。所以基于以上的学员提出的需求，马哥评估后感觉难度一般，所以给大家布置成学员作业给大家，希望大家积极的参与这个作业的完成，在vip群中秀出你的多屏壁纸异显的实战成果，看看你们谁先完成这个作业哈。明显看到主屏和副屏壁纸可以展示不同的壁纸，也app也可以单独进行设置对应的屏幕的壁纸。