Scrcpy是一个开源库，可以基于ADB（安卓debug bridge，官方调试工具）来实现安卓的远程桌面控制。ws-scrcpy是对这个库的一个包装，主要是把Scrcpy的功能搬到了网页端（顺便也搬运了一些ADB的功能）。
类似的还有qt-scrcpy，就是给scrcyp套了一个Qt的UI。
效果展示
从图中我们可以看出，这是一台作为终端的安卓手机直接打开了一个浏览器页面，这个页面正在控制另一台安卓手机打开微博。
基本实现
在基础实现里，只考虑在同一个内网中一台设备控制另一台安卓手机。
需要的硬件
- 被控制的安卓手机（废话……）
- 一台额外的PC机（windows、mac、linux都可以）
- 一条数据线
PC
只需要按Readme安装ws-scrcpy（https://github.com/NetrisTV/ws-scrcpy）即可。
安卓手机（被控制的）
打开USB调试模式。有些手机还需要关闭部分调试安全设置（比如允许adb控制输入等等）
所以，被控制的安卓手机，除了知道自己授权了另一台设备控制自己，以及知道现在自己在被控制之外，什么也不知道。既没有安装任何应用，也没有把数据暴露给第三方。
连接方式
控制端的浏览器访问http://PC_IP:8000即可。
远程控制有三个解码器可以选择Broadway.js、H264 Converter和Tiny H264。
实测下来，H264 Converter效果最清晰，最流畅，其余两个即使调整了分辨率和码率都还是更模糊一点。但是显而易见的，H264 Converter需要控制端的设备支持（虽然我想象不到2023年了，都开始H265了，还有设备不支持264？）。
一些拓展
PC开放给公网
毕竟这个库是个node的server。只要有办法可以把PC机开放给公网，那么就可以在任何地方远程控制被控制的安卓。
需要注意的是，这个库本身不提供任何认证授权的功能。所以暴露到公网需要自己想办法加认证。
远程ADB
显然，PC和被控制的安卓手机之间无非就是ADB连接。而ADB是支持远程的，那么理论上，手机也可以在任何地方被访问。
需要注意的是，ADB的远程连接是没有加密和认证的。
我的场景
印度APP专用机
具体的原因就不说了，懂得都懂。
结果就是，我专门买了一台印度手机专门安装印度的app。
且这台手机使用且仅使用其系统自带的应用商店里的应用，绝不安装任何没有经过其应用商店上架的应用。
所以，安装VNC server或者team viewer基本就是不可能的。应用层面只剩下向日葵之类的，但是这类app会把数据暴露给提供商，所以也不是我能接受的。
印度专线
懂的都懂，印度手机自然应该使用印度网络。
结果就是，路由器会直接针对这台手机做一个透明代理。然后这台手机发出的所有流量都会和在印度一样。
在只允许这台手机访问印度网络的同时，路由器允许内网的其他设备访问这台手机。
所以，有一台Windows通过远程ADB连接到这台手机其实没啥难度。
印度专用Windows
懂的都懂，和印度APP专用机一样。只是改成了Windows，专门装印度应用，走印度专线。
自然，这台Windows也是负责连接印度专用安卓机的那台Windows。
认证授权
我自己是没有把node暴露给公网的。所以，我的认证方式就是看终端设备有没有内网访问的权限。
FAQ
- 为什么不用AVD？或者模拟器？
一、我希望从硬件、系统一直到软件和网络，都是一台纯粹的印度设备。
二、还要插印度的电话卡的。 - 为什么要走透明代理？
一、系统HTTP代理不会禁止app直连。实测，真有直连的。
二、V什么N更是不可能的。一台正直的印度手机怎么会有这种东西？ - 为什么特别针对印度App？
一、把整个方向倒转一下，一样的原理，不一样的效果。懂的都懂。
二、非魔改系统感觉确实不错。至少我只需要对付G厂一个，而且G厂还比A厂给我留的空间大。
三、后续很快就会有非印度专用机。主要负责什么A字头、L字头的购物软件，或者水电费App之类的。 - 这么做的必要性？
一、反正至少现在两边给推的广告差异已经越来越大了。
二、要什么权限就要吧，都可以给。 - 为什么要远程ADB？有线不会更稳定吗？
一、走线难度太大了，走有线不够美观。
二、这个手机也会带出门的，直接电话卡开漫游，漫游回印度。 - G厂真的可以相信吗？比A厂好吗？
一、信任是一个很主观的东西。我其实不信他是什么好东西，但我也不信他是什么坏东西。我只是觉得G厂做事至少不会太离谱，所以很大部分的个人数据我觉得G厂拿到也没啥。
二、好坏本身其实是价值判断，也是个很主观的东西。A厂环境太封闭了，如果全面屏蔽A厂的流量手机就基本很难用了，G厂我还有机会自己抄印度的作业。而且G厂本身的生态其实不必A厂差太多，真正差的其实是……
三、至少G厂不会主动杀V什么N进程，也暂时看不出他在不同网络环境下有什么不一致的行为（所以姑且相信G厂不会主动试图绕过）。所以，反正流量会到我的家里洗一遍，全部放行那是情分，全部拦截是本分，开关在我手上就行。
优缺点
优点
- 被控制设备无感知。除了知道自己被开启了USB调试，以及知道有设备正在控制自己之外，其他什么也不知道。
缺点
- 成本较高。至少需要一台额外的中间设备。
- 图形效果不佳。毕竟远程套远程。
- 没有声音。
- 如果不想限制在局域网内的话，对网络基础设施要求较高。
弯路
其实吧，一开始，我是用qt-scrcpy的……大概方案是安卓远程桌面到Windows，然后Windows开一个窗口远程桌面到被控的安卓。
听着就很卡……
但更卡的是，那台Windows还是一台虚拟机里的Windows，视频解码性能拔群。可以说是卡的飞起。
但怎么说呢……可能是我搜索的方式不太对，反正一开始我是没找到这个工具的。也是摸着石头过河才最终找到这个方案。