看一些Android应用，特别是涉及到底层的功能性的应用，比如游戏加速，修改内存，挂机脚本神马的，发现里面的通信机制无一例外的都是使用的socket，基本上已经成为这类应用的一种标配了。

因为这类应用有以下的几个共同点：


1 需要android 手机的root权限，毕竟要修改一些比较底层的东西，没有root权限有时候木有办法修改啊


2 有自己的so，同时比较重要的或者比较吃力的活都编译成一个可执行的elf文件，然后让apk应用给这个elf文件给启动起来。关于这个elf文件放置的位置也有几种选择。


情况1:直接放在应用包下面的lib目录下，然后给这个可执行文件赋予一个可执行的权限。


情况2：放在assets文件夹下面，在程序启动的时候拷贝到files文件夹下面，赋予可执行的权限后，然后执行


情况3：也是放在assets文件夹下面，只不过安全性高一点，一般会做一个简单的异或或者移位加密，然后修改以下扩展名，拷贝过去的时候减密一下。再执行，有时候执行了以后会把真正的elf文件再给删除了。


3 可执行的so文件和java应用程序之间的通信使用socket，因为毕竟可执行的so才是真正干活的主力，而java应用程序要给so发送指令，而so也要给java应用程序反馈一些有用的数据供上层显示给用户。关于socket通信的方式也有下面的几种情况


情况1: 可执行的so作为server端，java应用程序给其发送指令的时候主动去链接可执行so，发送数据，有时候so也会返回一些数据，一般这种情况so就直接把活给干了，比如游戏加减速。


情况2：可执行的so文件作为客户端，同时使用长链接的方式，这种情况就需要java应用程序作为server端了，这里的稍微巧妙一点的是不采用固定的socket的端口号，而是java应用程序在创建socket的时候使用系统自动分配的端口号。不过需要通过java应用程序在启动可执行so的时候将端口号传递给so文件。


原理基本上就这么多了，下面的是一个例子，这个例子涉及到的编程技术主要是java应用程序自己创建socket的客户端和服务器端，然后进行通信，同时也启动了一个so的可执行文件，通过进程之间的数据流，向可执行的so发送数据，可执行的so将接收到的数据通过log给打印出来。


进入demo例子，


点击启动 socket server


这个时候log会打印出来


11-04 15:56:28.341:V/cheatecore-server(5774): server port = 44034


这样的数据，


由于serverSocket = new ServerSocket(m_port);


其中 m_port 为0，所以端口号是系统临时分配的。


然后socketserver 就开始等待有客户端的socket 来链接


m_socket = serverSocket.accept();


其中 accept 是阻塞函数，会将这个线程阻塞掉的。这个时候


通过 adb shell 进入android手机，使用 netstat –an | busybox grep 44034 查看，发现是这样的现象


显然这个端口是 listen 状态


然后点击设置客户端socket端口号和启动客户端socket


11-04 16:03:11.067: V/cheatecore(5774): 获取服务器端的端口号:44034
11-04 16:03:15.575:V/cheatecore-client(5774): client socket begin
11-04 16:03:15.575:V/cheatecore-server(5774): a client socket come here!!!


这个时候出现了a client socket comehere!!!
这条log再次执行刚才的
netstat –an | busybox grep 44034
发现已经变成如下的结果了

已经有随机分配的客户端端口号跟server端建立了链接了


然后再点击获取数据流


reader = new BufferedReader(inputreader);
serveroutwriter = new PrintWriter(newBufferedWriter(new OutputStreamWriter(sk.getOutputStream())),true);


主要获取socket的输入流和输出流，也就是客户端和服务端的tcp链接已经建立起来了，剩下的就是通过流来接收和发送数据了


接着点击
启动服务器socket 接收数据线程


String sReader = reader.readLine();
这条语句就在等着客户端的socket数据过来呢，其中readLine是一个阻塞函数，熟悉c语言的同学，其实这个就是socket 中的 recv函数，阻塞调用了。




因为tcp是全双工的，并且当前状态是长链接，所以服务端可以向客户端发送数据，客户端也可以向服务端发送数据，下一个按钮


服务器端socket发送数据


11-04 16:11:19.810: V/cheatecore-client(5774):客户端接收到服务端的数据:server data
11-04 16:11:19.810:V/cheatecore-server(5774): 服务端接收到客户端的数据:clientdata


这个时候出现的log，客户端在收到服务器的数据以后，也会向服务器端再返回数据，这样就完成了一次交互，但是其实这个时候socket并没有断掉，因为是长链接，可以进行多次发送


最后结束socket


关闭了socket，这个时候再用 netstat –an | busybox grep 44034
这个指令来进行查询，发现如下图：

刚才建立的socket已经释放了，再过一会查询wait超时后也会将端口释放掉了


测试向启动的进程发送数据


11-04 16:15:11.278: E/cheatecore(6163):input target main function!!!!
11-04 16:15:11.278: E/cheatecore(6163):scanf input content is 44034


主要过程是首先启动


/data/data/com.example.sockettest/files/target
这个程序


testprocee =Runtime.getRuntime().exec(cmd);
PrintWriterpoutwriter = newPrintWriter(newBufferedWriter(newOutputStreamWriter(testprocee.getOutputStream())),true); 
poutwriter.println(test);


然后发送数据，完成了这次进程间数据的交互，其实这也是进程之间通信的一种方式，和利用socket完成进程之间的通信并列的。