learnframework的博客

但是大家注意哈，正常情况下确实一般分屏模式的两个task是mode为multi-window，但是大家注意mutilwindow却不一定为分屏模式哈，比如以前的车载桌面那个Activity嵌入显示的模式，也是multiwindow但不是分屏模式。这里的AdjacentTask属于熟悉而又陌生的方法，熟悉在于你经常见到它在framework代码中，陌生在于你可能没有本质理解它什么意思，想不到它的实际场景。简单说就是Task1和Task2分别设置对方成为自己的AdjacentTask，形成如下图的依赖模式。

成果展示：明显上图可以看出在拖动自由窗口过程中，已经没有出现工具栏和Activity显示宽度不一致的问题了。问题本质原因修复方案总结：核心问题就在于CaptionWindow在systemui中进行刷新，而Activity是在应用进程单独刷新，在拖动时候会不断修改Activity和CaptionWindow相关的bounds大小，但是二者又处于两个进程单独刷新，导致没有掌握好刷新节奏，这类问题在分屏课程，ShellTransition课程中其实也是有详细讲解的。

但是近来有学员朋友在对自由窗口进行相关的拖拽操作时候，有遇到这个工具栏相关的一个bug，刚好aosp上面也确实可以复现，这里就拿出来分享给各位学员朋友，刚好可以拿来尝试练手，从而巩固在aosp14/15上自由窗口相关的实战经验。明显看到上面的工具栏的大小在拖拽过程中和自由窗口Activity的宽度不一样大了，看起来就有错位现象，抓取出其中一帧有问题的看看。在aosp14版本及以后版本上，安卓的自由窗口部分的工具栏部分都有了较大的更新。1、课程的freeform相关知识。2、课程的Winscope的相关。

简单说就是学员朋友反应自由窗口置顶后，发现无法通过systemui的侧边栏返回手势进行返回了。课程时候，有一个需求就是实现自由窗口置顶的功能，这个需求实现后，自由窗口就会一直处于顶端，不会因为打开其他Activity导致自由窗口退出。明显看到焦点输入在自由窗口上，但是操作侧边栏依然是底部的联系人窗口退出的，自由窗口的联系人无法退出。2、设置自由窗口为置顶模式，让自由窗口处于顶部，具体方法可以看马哥分屏课程自由窗口最后一节。可以看到要实现的目标就是侧边栏滑动后退出是有焦点顶部自由窗口Activity。

可以采用Windowless图层，让Windowless图层需要挂载在Task的父亲，而不是Task哈，因为Task本身被设置了WindowCrop，会裁剪掉面积大小，导致显示异常，所以这里要挂载到Task的显示区域大的父亲上。然后在GPU绘制时候，可以考虑使用skia绘制一个阴影图层，这个在SurfaceFlinger中gpu合成绘制时候是可以使用skia相关的api绘制阴影，具体skia代码如何绘制实现可以参考原来。2、阴影View正常要比Task区域显示要大一些，这样才可以有外阴影的效果。

这些其实都是采用Windowless的方式添加上去展示的，Windowless可以简单字面意思理解为无窗口的画面，即可以看到显示内容画面，但是它并不属于WindowState。3、理论上所有Windowless显示内容都可以使用正常WidnowState显示，但是因为wmshell中有很多额外窗口需求，这样可能会需要额外增加比较多的窗口类型type，这样针对一些少见业务场景，然后去改动整个wms层级结构树的业务成本太大，即实现了一些业务窗口与整个系统窗口结构管理的解耦。

因为本质上划线只是一个自定义的OutlineLayout，所以只需要把当前的绘制矩形变成绘制圆角矩形既可以，但是绘制圆角矩形肯定需要圆角的半径和自由窗口的圆角半径保持一直，所以这里需要把自由窗口圆角半径设置给OutlineLayout。2、针对使用canvas.drawRoundRect绘制圆角的矩形。下面就带大家来解决这样一个小需求小问题。1、提供设置圆角半径的接口给外部。

本文主要带大家认识了一个新的StartingWindowType：STARTING_WINDOW_TYPE_SOLID_COLOR_SPLASH_SCREEN，它主要就代表当前SplashWindow展示的固定的一种颜色背景，没有Icon图标展示。在分屏进入动画过程中其实是也可以看到Splash的图层，但是真实画面录屏看不出来，其实是因为纯色背景自身有alpha值后就看不出来，还有就是Splash窗口自身在真实Activity启动后Splash窗口自身也会有相关的隐藏背景内容的情况。

在framework系统是属于一个很复杂的体系，每个小分支都会有很多不同的处理方式等，所以当使用正规的思路打堆栈分析不出来时候，不应该直接放弃，更应该从逆向，或者多角度来尝试探索分析，这样才符合实际项目中遇到各种问题都可以使用学习的知识灵活应对，而不是仅仅套一下模板，一旦有一些异常变化就又不知道如何分析，教给各位粉丝的知识一定要活学活用哈，整体理解多角度分析。更多framework实战干货，请关注下面“千里马学框架”

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

核心看看这里的topPosition，bottomPosition是怎么计算的，刚好也可以解释为啥这里名字有16_9这个字符，其实本质就是计算个topPosition位置，拿竖屏来举例的话，这里因为想要屏幕宽度固定的，为了美观程度，所以一般topPosition这个区域要固定为一个16：9区域。上面已经分析出了分割线的几个SnapTarget，这些SnapTarget都是有固定位置的，那么接下来分析一下分割线如何到对应的SnapTarget。

调研竞品是如何实现的方案，那当然需要有竞品的设备，可以进行相关的dumpsys，这里因为手上没有su7的车机和汽车可以进行dump，所以暂时没办法进行实际的dump设备查看，即无法分析出小米su7是如何实现的这个3分屏。好了暂时想到就是上面3个方案，其实还是比较推荐方案1，毕竟交互动画体验可以较多的复用2分屏，但是复用也意味着修改较多原来的逻辑，这个暂时还没有时间实战实现这个功能，各位学员们有兴趣可以去尝试实现一下。彻底不使用原来的分屏方案，使用自由窗口方案，整体的3分屏，其实就是3个自由窗口显示着。

一些vip学员朋友也纷纷求助马哥的实现patch代码，想用于公司的实战项目实现。但是在公司需求实现要求和马哥这边的实现还是会有一些需求上的变更和设备环境差异，所以使用过程中学员朋友们也提出了一些额外的问题。这个问题其实在马哥自己设备上从来没有发现过，但是有的vip学员朋友和我反馈有这种黑屏不显示情况，针对这个问题第一时间进行了分析，主要通过提供的dumpsys SurfaceFlinger来查看。2、因为上下结构已经实现，如果左右结构，针对触摸部分，如果左右结构需要更改触摸区域的宽度变宽。

因为Caption是属于单独的图层，和Activity的图层都不在一个，而且Caption图层是显示在Activity图层的顶部，而DecorView等明显是Activity图层的一个View，边框红线自然就被Caption栏给遮挡了。即新建一个划线图层处于Caption图层的上面，这样划线图层就可以在自由窗口最顶部进行显示，不会被遮盖，具体实现其实就可以同样参考Caption实现 ，搞一个Windowless的窗口进行绘制。即自由窗口在被触摸放大缩小时候，边框要被画成红色的线条，表示选中。

注意这里的这里的CaptionWindo其实并不可以通过dumpsys window windows这样方式看到它，说明它本身不是一个windowstate，不受窗口层级结构树管理。拖拉上面的CaptionWindow部分。边角触摸点击拖拽放大。

上面已经分析清楚了本质是因为有了SurfaceView以后，系统会设置对应的TransparentRegionHint导致最后的Activity的Layer只显示在非SurfaceView部分，SurfaceView部分区域直接不会被绘制。图库的Activity因为有一个SurfaceView，这里的SurfaceView会导致有单独的Layer，真正显示红框部分属于非SurfaceView部分，但是SurfaceView部分的就完全没有显示出来。那么上面的HWC的输出中为啥Layer又确实被切割了呢？

这个比较常见一些，比如在一些背景大屏幕上，其实厂家一般没办法直接做出一个巨大屏幕的背景，主要原因还是因为面板尺寸太大，成本太高，而且也不是很常用，只是在很小一部分景使用。这个需求其实嵌入式相关很多有现成的方案，我们这里实现方式就不是说嵌入式层面方案，而是让大家考虑一下在framework层面，应该如何实现？近来学员vip群里讨论屏幕相关的需求比较多，有2个需求属于粉丝朋友都比较感兴趣一起讨论的，这里刚好做一个记录，方便其他粉丝朋友看看。2、车载多屏互动相关知识。3、input相关知识。

在学习了马哥的wms和多屏互动课程后，大家普遍都可以跟着做出如下图效果的多屏互动

看一下堆栈是不是很清晰整个startActivity的过程，清楚知道在哪里启动的onClick且一步步到对应的startActivity，这里寻找最贴近context的startActivity，那就是。看到确实是可以启动Freeform模式的App，不过好像窗口的坐标不是我们设置的，一直显示在左上角，而且状态栏还遮盖了，导致无法拖拉自由窗口，那么到底啥原因导致该问题呢？硬看代码，这里就需要自己先了解launcher的app图标代码，去寻找app的图标点击onClick方法，一步步寻找。

1、对于ActivityRecord来说相对非常简单，就是ActivityRecord的windowmode跟着Task混就可以了，Task的WindowMode是啥就是啥2、针对新创建的Task情况有点不一样，他们和启动这个新建Task的sourceTask有关系，如果sourceTask里面是分屏相关的task那么新建Task的的Parent就会变成和sourceTask的一样的rootTask，否则就是TaskDisplayArea即没有rootTask。本文章更多详细代码和资料需要购买课程获取。

当前的原生letterbox确实一定程度上解决了竖屏app在横屏显示的问题，但实际上了各个应用后问题还是很多，特别是对各个app展示适配情况，一样有很多很多的ui显示问题。这个希望各位学员积极参与哈

做相关分屏做小桌面项目时候，因为原来课程版本是基于android 13进行的讲解的，但是现在公司已经开始逐渐进行相关的android 14的适配了，但是android 14这块相比android 13还是有一些差异，适配起来有点，刚好借此机会给大家分享一下。目标就是为了可以调用ISplitScreen相关接口，aosp13的SplitScreen其实本质也是调用的ISplitScreenImpl的接口。可以看到是在这里进行的putBinder对象，放到了Bundle传递到了launcher进行。

明显可以看出这个代表移动taskId到分屏的sideStagePosition，注意了，这个命令只需要指定一个taskId和他的position既可以，那么这里大家会有疑问那么另一个分屏该显示谁？代表成对显示的意识，即吧taskId1和taskId2进行成对显示，即分屏，但是这个分屏和桌面进入的分屏是不一样的，核心不一样的点就是层级结构树都不一样，具体看如下实战。当前task层级结构树的最顶部符合分屏要求的task，一般就是最顶端的task。这个时候就需要有一个可以直接通过命令行拉起分屏的需求是最好的。

进行queue动作完成后，紧接着就是runInSync执行，这个方法参数非常关键，代表是一个同步事务等待同步后进行回调执行的部分，而且这个时候会有一个Transaction的参数，里面就包含了相关WindowContainer的绘制相关事务。注意对于prepareSync属于WindowContainer的基类方法，Task没有实现那就是默认WindowContainer实现的，所以一直会调用到有自己实现的WindowState的。

近期有个马哥学员刚好求助马哥一个关于以前马哥课程里面自由窗口项目，这个项目在android 13上做的，但是他们公司是aosp14，希望我能帮忙尽快升级到14。今年2023年已经块过去了，各个手机厂商已经开始适配aosp14，甚至有的是已经适配完成，明年市场就大部分手机出厂就都是android 14了。马哥课程中自由窗口效果可以看出来基本和国内手机各个大厂自由窗口效果是不是大体相同，课程实现是带大家手把手进行实现的。1、把原来的自由窗口自己的顶部栏显示等，独立成了一个窗口，移植到了如下目录。

整个多屏输入法的流程涉及到了3个进程---->焦点app发起startInputAsyncOnWindowFocusGain------>systemserver stop老的service，start新service-------->输入法进程创建新的service onCreate执行------->输入法创建带有display的context-------->创建对于输入法窗口带有新的display更多framework干货获取相关可以 私聊+v(androidframework007)

上面就是一个非常真实的企业实战的bug，而且也很经典，很符合很多人修改framework的需求的情况，毕竟大家都很喜欢看到快速修改效果，这期间很可能你会去百度啥的copy人家代码，跑起来了就一顿开心，可是往往没有深入理解透彻，可能就是你挖出天坑第一步，后面测试一测相关引入的bug，就是对你前面偷懒的惩罚哈哈哈，总之告诉你，想彻底掌握那么就必须要全面理解。我就改了个配置而已，为啥会引入个黑屏的bug，这下完蛋了，压根不知道为啥引入的啊，修改就那么简单两句代码而已。一切都完美，准备公司得表扬了。

明显发现触摸派发window层级方面还是以桌面为顶部window，地图为底下window，这样其实也可以理解，我们上面的说的情况一样，其实整个画面都是CarLauncher的，地图Activity也只是CarLauncher的一个View而已。这里就说明了CarLauncher虽然在顶部，但是他的touchRegion根本没有包含地图Activity的区域，所以派发事件时候根本不会抢地图Activity的，即地图区域的事件不会派发到桌面。2、TaskView的Activity是怎么可以接收事件的呢？

1、桌面调用到sysui获取Task信息，因为sysui中其实有分屏相关的TecentTask信息。2、sysui也是调用到atms进行RecentTask的信息获取。这里其实会调用的sysui的getRecentTasks进行查询。

前面的blog都是对于最新的android 13源码进行分析的CarLauncher的实现方案，已经知道CarLauncher使用是TaskView来装载新的地图Task，但是在android 12版本以前其实不是使用的TaskView的方案实现的，而是使用的ActivityView方案。

总结：上面几步最重要就是与systemserver端建立了联系，而且把相关的回调的mInterface传递到了systemserver端，这样systemserver端就可以在Task有变化情况下通过mInterface通知到客户端。上面第一步已经实现了CarLauncher可以监听Task的相关行为，注意这里肯定是所有的Task行为，但是TaskView它自身只关心Map相关的Task，那么这里是怎么精准通知的呢？通过这个cookie即可以精准的把系统回调的TaskInfo匹配到对应的TaskView。

hi，粉丝朋友们！今天来给大家介绍一下再Activity中WindowMode相关的多窗口模式，这个模式相对平时比较少见，但是在分屏模式之自由窗口模式，等存在多个窗口场景就很关键了。这一部分确实不是普通模式的场景，而且每一种模式都是比较难的，今天来分析一下WINDOWING_MODE_MULTI_WINDOW模式的一个疑问。

aosp默认并没有公开自由窗口模式，如果需要体验自由窗口模式必须要用如下命令进行开启输入完成后，可以在多任务的menu中发现freeform：点击这个freeform按钮即可以进入到自由窗口模式。

2、针对task相关的2类操作，reorder和startTask两类都是包装成了HierarchyOp，对这类也是调用了applyHierarchyOp方法来进行处理。总体来看这个reorder相对来说操作还是比较简单，就是一个把RootTask放到第一位，即显示再最前面。的话这个看起来也很简单，对上面3个步骤也非常好理解，甚至可以自己写出相关的代码。可以看看通过下图先有个大概的Task区域及结构的了解，其实这个如果前期学习过。这里其实也可以猜想出systemserver端也一样要有类似的3步操作。

这里注意最后桌面调用了mSplitScreen.startIntentAndTaskWithLegacyTransition，这里的mSplitScreen就是一个binder代理，会调用到systemui的服务端。已经计算好了分屏的bound后，就需要把bound设置到WindowContainerTransition中进行传递，到了关键的：updateWindowBounds(mSplitLayout, wct);刚开始是SplitLayout的init。这个和reorder没啥区别。

其他TaskView动画就不进行相关的介绍了，都在这调用堆栈里面，到此时分屏在桌面多任务完成了第一步，把TaskView放到顶部（上屏），接下来要等待用户来手动选择一个下屏app，才可以构成真正意义的分屏。这里createTaskDismissAnimation其实就是上面那个短信应用上半屏幕部分显示的动画构建。点击后会动画进入如下图一样状态，这个短信app放到上面，下面多任务依旧是多任务，位置确实变化了。

上面代码已经清楚到了ViewRootImpl已经把对应的PipMenuView设置到了ViewRootImpl，但是好像并没有看到PipMenuView这个图层有添加到SurfaceFlinger图层，其实核心还是在ViewRootImpl。上面就已经讲解清楚了PipMenuView这个画面是怎么一回事，为啥dumpsys window看不到，但是surfaceflinger结构树可以看到。这里又发现是调用了PerDisplay的addView。是否发现又多了3个按钮，但是这个窗口到底是啥呢？

这里发现较为简单，功能就是响应一下onClick，然后启动hideMenu,会启动一个动画进行hide。

综上就清楚了pip的触摸事件其实是自己使用独立的inputchannel进行的接受，和pip这个activity的窗口inputchannel没有啥关系。其实核心是PipInputConsumer类，这里可以对PipInputConsumer进行详细分析。结下来分析一下松手后，才会真正对Task的Bounds进行设置相关堆栈。接下来重点看createInputConsumer。

1、进入pip时候，即进入pip的动画过程，是属于fullscreen的状态，但是task已经是pip了，所以需要ActivityRecord自己对应的override。大概意思就是在进入pip动画过程种要禁止activity进行显示上面的变化，所以要设置为fullscreen的mode，等待动画完成才可以变化windowmode。因为小窗pip虽然进入了pasued状态，但是visible还是可以显示的true状态。systemui进程进行动画结束以后，会进行对应的setBound的设置。