近来反编译看一些Android应用，特别是涉及到底层的功能性的应用，比如游戏加速，修改内存，挂机脚本神马的，发现里面的通信机制无一例外的都是使用的socket，基本上已经成为这类应用的一种标配了。
Android 使用Socket完成进程间通信例子见下面的下载：
具体下载目录在 /2013年资料/11月/5日/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 状态
推荐阅读：