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,视频解码性能拔群。可以说是卡的飞起。
但怎么说呢……可能是我搜索的方式不太对,反正一开始我是没找到这个工具的。也是摸着石头过河才最终找到这个方案。