beriru

> 首先，Android 源码越来越庞大，了解所有的服务工作量很大，因此有哪些服务已经被缓存排查非常困难。
> 其次，厂商越来越钟情于扩展自定义服务，这些服务不开源，识别和适配更加耗时。
> 再次，有一部分服务只有 native 实现，并不能通过 Java 层的接口代理进行拦截（如：Sensor/Audio/Video/Camera 服务等）。

如果只是为了解决 1,2 的话

https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/Binder.java;drc=074bb2dc367bde42b837a8de4d4e88f26c074c32;l=986

感觉这样就能解决大部分场景

@nnegier 你可以看看这个类的几个子类, pm 就是这么解决的
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/content/pm/BaseParceledListSlice.java

是指三星手表可以控制连接的三星手机上正在播放的油管的前进后退 media control 么?

如果是的话,理论上 通过 companiondevice 连接的手表都可以做到类似的,而且不止油管,任何实现正确的播放器都能被手表控制,以前研究过一点,大致原理如下

正确实现的播放器(音频/视屏)在播放时会在系统中注册为当前激活的 MediaSession, 可以收到 Media Control 事件的回调并且正确的切换状态
手表通过对应的 companion device app 获取系统中的 MediaSession, 传给手表,手表同步(如进度/playback 等)显示,手表上如果有用户的 Media Control 按钮事件,回传给 cda, cda 通过系统接口传到当前激活 MediaSession 的 播放器, 播放器做对应的事件

远一点说, 锁屏上的 MediaStyle 通知, 线控耳机的按钮, 都是差不多走的这一套逻辑,
android 系统这一点做的非常统一和抽象, 非常棒

@gentrydeng
能这样做的前提是当前浏览器(WebView)在 shouldOverrideUrlLoading 中解析了 intent scheme 并且 startActivity(Intent.parseUri(xxx)), 大部分浏览器不会这么做,因为存在安全问题