Android的硬件访问服务提供了一个APP调用硬件实现的方法模型。我们从上往下来看。应用层面对的都是一个个的服务叫service.比如电源管理服务，震动服务等等。应用层代码首先就需要去查询系统是否存在这么一个服务，或者目前是不是可以被获取的。从这个角度，我们就牵扯出来两个问题。a：既然去系统里面查找这么个服务，那么首先应该又什么地方注册加入系统的。b:有了这么个服务，我也得创建一个接口函数来链接APP跟这个服务函数的桥梁。我们的应用APP通过这么一个桥梁来去访问这个服务。
我们需要怼的就是这么个服务是怎么添加到系统的，以及他的前世今生。这个工作是由systemserver.java文件来做的。在 startotherservices函数中我们先去new 一个服务实例对象，然后再去addservice 将这个方法注册到系统的service_manager.c这就是前面我说的系统。那么这个服务的方法是根据谁来实例化的呢？那么肯定会有一个class类来做，也就是说我们需要创建这么一个类。
APP操作的根源还是在底层，现在我们讲好了service,那么我们还需要一个地方去注册管理底层的方法。这个仍旧是在SystemServer.java里面集中管理。这个是通过Loadlibrary函数调用JNIonload。cpp这里面并没有直接做JNI的处理，因为安卓各个方法如果都写在这么一个文件里面就会显得特别乱。我们继续通过调用下一层的JNI文件来处理。这个JNI文件是需要随着系统一起编译的。后期我们没改一次JNI就去编译一次Anroid系统，太费劲了。我们就引入了Hal文件。我们的jni只需要提供标准的接口。hal文件去实现这些jni。而且这些hal文件不需要跟着系统一起编译，我们还可以把他做成.so文件，加载到库里。这样同时还解决了保密问题。对吧。
说的还是挺绕的。简而言之。我们把底层各种封装处理，然后提供处理啊那么一个插头（我们的service实例化后的方法就是一个插头，里面包含了各种处理）。我们的应用层也使用一个插头，当这俩插头接到了一起，就实现了我们的安卓硬件访问服务。

如果某个硬件资源只能被某一个应用使用，可以使用下面的方法访问硬件：