ArcIntentHelper流程及依赖

ArcIntentHelper的作用简而言之就是同步chromiumOS这端的用户操作和系统设置信息到安卓端，使两个系统用起来像一个系统。   具体实现的小功能包括但不限于：在chromiumOS端文件夹点击apk或者图片、音视频及文档 能够将这些文件通过ArcIntentHelper让安卓端的相应应用打开。 chromiumOS端的系统设置能够通过此服务同步到安卓的设置中，例如时间、时区、GPS、语言、无障碍、代理、蓝牙状态...   还能够实现chromium浏览器打开的页面同时让安卓端的浏览器打开。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~依赖环境及各个模块的作用~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ArcIntentHelper所依赖的服务包括chromiumOS端和安卓端。  chromiumOS端主要是依靠浏览器mojom服务和对应的host实现。  安卓端依赖的服务比较庞大和复杂，包括但不限于framework层的ArcDocumentsUI、ArcVolumeManage，Native层的vold中的ArcVolumeMounter、ArcAppfuse、ArcObbMounter、ArcBridgeHostPtrService。下面将给出依赖框架和各模块说明：

( 箭头表示依赖，直线表示通信)

 

1. 上图中ArcEmulatedVolume是实现download分区挂载到Android的sdcard的，详见[AndroidContainer]sdcard分区挂载问题已知点分析(已实现)

 

       2.  实现挂载后在安卓的文件管理器就能看到chromiumOS端的Download文件夹内的文件了，但是其他软件是看不到此文件夹内的内容的，需要ArcDocumentsUI的服务才能够让其他软件和服务看到。此服务是需要FileSystem这个mojom实现的，具体功能和流程可参考https://www.cnblogs.com/zqlxtt/p/4451949.html     在Android7中 chromium发送过来的uri 例如：content://org.chromium.arc.intent_helper.fileprovider/download/filename是通过intent1.setComponent(new ComponentName("com.android.documentsui", "org.chromium.arc.file_system.ArcFileSystemActivity")) 这个intent调用ArcDocumentsUI中的ArcFileSystemActivity打开。到了android9中 chromium发送过来的的uri就直接是content://org.chromium.arc.file_system.fileprovider/download/filename  直接交给ArcDocumentsUI进行打开，并不经过intenthepler进行转换了。 （未实现）

       3. ArcBridgehostPtrservice是基于ArcBridgeService将ArcBridgehostPtr* 通过socket服务分发给请求者的服务。使native层的请求者能够拿到ArcBridgehostPtr* 从而进行初始化打通对应的mojom服务。（暂未完成）

       4. ArcVolumeMounter 是基于volumemounter mojom为实现将chromuimOS的mountEvent及时通知Android端进行处理的，例如ChromiumOS有U盘插入，那么此事件会通过volumemounter mojom通知安卓 进行updateVirtualDisk 并对对应的事件进行处理更新。（未实现）

       5. ArcAppFuse 是基于AppFuse mojom实现的，功能是为安卓内的应用提供sdcard文件系统 将apk产生的数据都储存其中。每有一个apk需要储存权限就会向vold中的appfuse申请并创建目录，ArcAppFuse就会在ChromiumOS这边准备一块区域挂载给安卓用来存放应用目录和数据。申请好空间和目录也是通过mount bind从android /var/run/arc/内进行绑定。可参考https://android.googlesource.com/platform/system/vold/+/419528be57a37930e662b2acdfebef52f491fec5/AppFuseUtil.cpp 进行实现。（未实现）

       6. ArcObbMounter 同样也是基于obbmounter mojom实现的。/var/run/arc/obb：这是从主机的/run/arc/obb绑定挂载的。在容器外部运行的名为/usr/bin/arc-obb-mounter的守护程序在请求时将OBB映像文件作为FUSE文件系统挂载到目录。同样需要在Android内mount bind到对应目录。附上obb 路径的作用： 如果我们设计一款资源包含比较多的游戏，可能你会发现最终生成的APK文件可能高达300MB，但是APK文件很大导致Android系统无法正常安装，而这么大其实都是游戏中用到的资源文件，我们放到SD卡上可能其他应用也可以访问，比如说系统的图片管理器会索引游戏中的图片资源，而音乐播放器也会索引资源中的音乐，所以Android 2.3的OBB文件(Opaque Binary Blob)可以很好的解决大文件在SD卡上分离出APK文件，同时别的程序没有权限访问这样一种隔离的文件系统。（未实现）

       7. ArcVoldNativeService 为vold和framework层通信和对obb等模块操作提供接口，功能可参考VoldNativeService.cpp。（未实现）

       8. IArcVold 猜测是与framework层binder通信的接口服务。（未实现）

 

更进一步的vold的框架和流程可参考：原生安卓 vold 流程及框架

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ArcIntentHelper流程~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ArcIntentHelper的主要功能就是在ChromiumOS端的文件管理器点击文件和设置，可以调用安卓中对用的应用进行打开和操作。下面简述其流程和逻辑。（这一切的基础是mojom已经打通和对应的方法已经实现了）

如上图所示，ArcIntenthelperService 服务初始化的流程是在IntentHelperReceiver收到bootcomplete的广播后就启动ArcIntenthelperService服务，此时会向ArcBridge请求同步信息并将IntentHelperReceiver传入的inten信息交给onstartcommand处理。ArcBridge收到请求后开始调用ArcIntenthelperService的init进行初始化服务，初始化成功后回调给arcbridge，之后通知Host端。ArcIntenthelper的mojom通信服务就已经就绪。随时供浏览器端调用。

      首先我们看系统设置服务。设置信息通过浏览器端发送给安卓端，IntenthelperService通过调用sendbroadcast来对对应的信息进行设置，并将一些不是设置的信息转发到系统供其他服务和程序接收。

 

      再看用户行为，用户通过点击浏览器端界面的文件或者浏览器链接，首先会发送一个请求给ArcIntenthelperService，请求对应的文件或者链接的处理应用列表。ArcIntenthelperService返回列表给浏览器端，浏览器端继续请求对应应用的图标，请求到图标后由用户界面显示出来。接着用户会点击某一个应用的图标企图用此应用打开刚才选中的文件或者链接。当点击打开应用后，浏览器端发送此文件或者链接的uri和action给ArcIntenthelperService，由ArcIntenthelperService的 handleUrlListDeprecated程序进行startActivity。如果是链接就会调用安卓端的浏览器，如果是文件就会调用ArcDoucmentsUI服务进行文件的读取和打开。之后就可以将对应的程序和结果显示给用户了。

 

      ArcIntenthelperService还有其它服务供安卓内部使用的，由于未完成测试有些功能尚不了解，所以在此先不介绍。

代码的产权归公司所有，所以再次不方便贴出项目代码，敬请谅解。