只要进程我复活的足够快，系统它就杀不死我！Android最强保活黑科技的最强技术实现！

int ioctl(int fd, int request, …);

作用：通过IOCTL函数实现指令的传递

• fd 是用户程序打开设备时使用open函数返回的文件描述符
• request是用户程序对设备的控制命令
• 后面的省略号是一些补充参数，和cmd的意义相关

应用程序在调用ioctl进行设备控制时，最后会调用到设备注册struct file_operations结构体对象时的unlocked_ioctl或者compat_ioctl两个钩子上，例如Binder驱动的这两个钩子是挂到了binder_ioctl方法上：

static const struct file_operations binder_fops = {
.owner = THIS_MODULE,
.poll = binder_poll,
.unlocked_ioctl = binder_ioctl,
.compat_ioctl = binder_ioctl,
.mmap = binder_mmap,
.open = binder_open,
.flush = binder_flush,
.release = binder_release,
};

它的实现如下：

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
/根据不同的命令，调用不同的处理函数进行处理/
switch (cmd) {
case BINDER_WRITE_READ:
/读写命令,数据传输,binder IPC通信的核心逻辑/
ret = binder_ioctl_write_read(filp, cmd, arg, thread);
break;
case BINDER_SET_MAX_THREADS:
/设置最大线程数，直接将值设置到proc结构的max_threads域中。/
break;
case BINDER_SET_CONTEXT_MGR:
/设置Context manager，即将自己设置为ServiceManager，详见3.3/
break;
case BINDER_THREAD_EXIT:
/binder线程退出命令，释放相关资源/
break;
case BINDER_VERSION: {
/获取binder驱动版本号，在kernel4.4版本中，32位该值为7，64位版本该值为8/
break;
}
return ret;
}

具体内核层的实现，我们就不关心了。到这里我们了解到，Binder在Android系统中会有一个设备节点，调用ioctl控制这个节点时，实际上会调用到内核态的binder_ioctl方法。

为了利用ioctl启动Android Service，必然是需要用ioctl向binder驱动写数据，而这个控制命令就是BINDER_WRITE_READ。binder驱动层的一些细节我们在这里就不关心了。那么在什么地方会用ioctl 向binder写数据呢？

IPCThreadState.talkWithDriver

阅读Gityuan的Binder系列6—获取服务(getService)一节，在binder模块下IPCThreadState.cpp中有这样的实现(源码目录：frameworks/native/libs/binder/IPCThreadState.cpp)：

status_t IPCThreadState::talkWithDriver(bool doReceive) {
…
binder_write_read bwr;
bwr.write_buffer = (uintptr_t)mOut.data();
status_t err;
do {
//通过ioctl不停的读写操作，跟Binder Driver进行通信
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
…
} while (err == -EINTR); //当被中断，则继续执行
…
return err;
}

可以看到ioctl跟binder driver交互很简单，一个参数是mProcess->mDriverFD，一个参数是BINDER_WRITE_READ，另一个参数是binder_write_read结构体，很幸运的是，NDK中提供了linux/android/binder.h这个头文件，里面就有binder_write_read这个结构体，以及BINDER_WRITE_READ常量的定义。

[惊不惊喜意不意外]

#include<linux/android/binder.h>
struct binder_write_read {
binder_size_t write_size;
binder_size_t write_consumed;
binder_uintptr_t write_buffer;
binder_size_t read_size;
binder_size_t read_consumed;
binder_uintptr_t read_buffer;
};
#define BINDER_WRITE_READ _IOWR(‘b’, 1, struct binder_write_read)

这意味着，这些结构体和宏定义很可能是版本兼容的。

那我们只需要到时候把数据揌到binder_write_read结构体里面，就可以进行ioctl系统调用了！

/dev/binder

再来看看mProcess->mDriverFD是什么东西。mProcess也就是ProcessState.cpp(源码目录：frameworks/native/libs/binder/ProcessState.cpp)：

ProcessState::ProcessState(const char *driver)

mDriverName(String8(driver))
, mDriverFD(open_driver(driver))
, …
{}

从ProcessState的构造函数中得知，mDriverFD由open_driver方法初始化。

static int open_driver(const char *driver) {
int fd = open(driver, O_RDWR | O_CLOEXEC);
if (fd >= 0) {
int vers = 0;
status_t result = ioctl(fd, BINDER_VERSION, &vers);
}
return fd;
}

ProcessState在哪里实例化呢？

sp ProcessState::self() {
if (gProcess != nullptr) {
return gProcess;
}
gProcess = new ProcessState(kDefaultDriver);
return gProcess;
}

可以看到，ProcessState的gProcess是一个全局单例对象，这意味着，在当前进程中，open_driver只会执行一次，得到的 mDriverFD 会一直被使用。

const char* kDefaultDriver = “/dev/binder”;

而open函数操作的这个设备节点就是/dev/binder。

纳尼？在应用层直接操作设备节点？Gityuan大佬不会骗我吧？一般来说，Android系统在集成SELinux的安全机制之后，普通应用甚至是系统应用，都不能直接操作一些设备节点，除非有SELinux规则，给应用所属的域或者角色赋予了那样的权限。

看看文件权限：

➜ ~ adb shell
chiron:/ $ ls -l /dev/binder
crw-rw-rw- 1 root root 10, 49 1972-07-03 18:46 /dev/binder

可以看到，/dev/binder设备对所有用户可读可写。

再看看，SELinux权限：

chiron:/ $ ls -Z /dev/binder
u:object_r:binder_device:s0 /dev/binder

查看源码中对binder_device角色的SELinux规则描述：

allow domain binder_device:chr_file rw_file_perms;

也就是所有domain对binder的字符设备有读写权限，而普通应用属于domain。

既然这样，肝它！

写个Demo试一下

验证一下上面的想法，看看ioctl给binder driver发数据好不好使。

1、打开设备

int fd = open(“/dev/binder”, O_RDWR | O_CLOEXEC);
if (fd < 0) {
LOGE(“Opening ‘%s’ failed: %s\n”, “/dev/binder”, strerror(errno));
} else {
LOGD(“Opening ‘%s’ success %d: %s\n”, “/dev/binder”, fd, strerror(errno));
}

2、ioctl

Parcel *parcel = new Parcel;
parcel->writeString16(String16(“test”));
binder_write_read bwr;
bwr.write_size = parcel->dataSize();
bwr.write_buffer = (binder_uintptr_t) parcel->data();
int ret = ioctl(fd, BINDER_WRITE_READ, bwr);
LOGD(“ioctl result is %d: %s\n”, ret, strerror(errno));

3、查看日志

D/KeepAlive: Opening ‘/dev/binder’ success, fd is 35
D/KeepAlive: ioctl result is -1: Invalid argument

打开设备节点成功了，耶✌️！但是ioctl失败了，失败原因是Invalid argument，也就是说可以通信，但是Parcel数据有问题。来看看数据应该是什么样的。

binder_write_read结构体数据封装

IPCThreadState.talkWithDriver方法中，bwr.write_buffer指针指向了mOut.data()，显然mOut是一个Parcel对象。

binder_write_read bwr;
bwr.write_buffer = (uintptr_t)mOut.data();

再来看看什么时候会向mOut中写数据：

status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
{
binder_transaction_data tr;
tr.data.ptr.buffer = data.ipcData();
…
mOut.writeInt32(cmd);
mOut.write(&tr, sizeof(tr));
return NO_ERROR;
}

writeTransactionData方法中，会往mOut中写入一个binder_transaction_data结构体数据，binder_transaction_data结构体中又包含了作为参数传进来的data Parcel对象。

writeTransactionData方法会被transact方法调用：

status_t IPCThreadState::transact(int32_t handle, uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags) {
status_t err = data.errorCheck(); // 数据错误检查
flags |= TF_ACCEPT_FDS;
if (err == NO_ERROR) {
// 传输数据
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
}
…

// 默认情况下,都是采用非oneway的方式, 也就是需要等待服务端的返回结果
if ((flags & TF_ONE_WAY) == 0) {
if (reply) {
//等待回应事件
err = waitForResponse(reply);
}else {
Parcel fakeReply;
err = waitForResponse(&fakeReply);
}
} else {
err = waitForResponse(NULL, NULL);
}
return err;
}

IPCThreadState是跟binder driver真正进行交互的类。每个线程都有一个IPCThreadState，每个IPCThreadState中都有一个mIn、一个mOut。成员变量mProcess保存了ProcessState变量(每个进程只有一个)。

接着看一下一次Binder调用的时序图：

Binder介绍一节中说过，BpBinder是Binder Client，上层想进行进程间Binder通信时，会调用到BpBinder的transact方法，进而调用到IPCThreadState的transact方法。来看看BpBinder的transact方法的定义：

status_t BpBinder::transact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) {
if (mAlive) {
status_t status = IPCThreadState::self()->transact(mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}

BpBinder::transact方法的code/data/reply/flags这几个参数都是调用的地方传过来的，现在唯一不知道的就是mHandle是什么东西。mHandle是BpBinder(也就是Binder Client)的一个int类型的局部变量（句柄），只要拿到了这个handle就相当于拿到了BpBinder。

ioctl启动Service分几步？

下面是在依赖libbinder.so时，启动Service的步骤：

// 获取ServiceManager
sp sm = defaultServiceManager();
// 获取ActivityManager binder
sp binder = sm->getService(String16(“activity”));
// 传输parcel
int result = binder.get()->transact(code, parcel, NULL, 0);

1、获取到IServiceManager Binder Client；

2、从ServiceManager中获取到ActivityManager Binder Client；

3、调用ActivityManager binder的transact方法传输Service的Parcel数据。

通过ioctl启动Service也应该是类似的步骤：

1、获取到ServiceManager的mHandle句柄；

2、进行binder调用获取到ActivityManager的mHandle句柄；

3、进行binder调用传输启动Service的指令数据。

这里有几个问题：

1、不依赖libbinder.so时，ndk中没有Parcel类的定义，parcel数据哪里来，怎么封装？

2、如何获取到BpBinder的mHandle句柄？

如何封装Parcel数据

Parcel类是Binder进程间通信的一个基础的、必不可少的数据结构，往Parcel中写入的数据实际上是写入到了一块内部分配的内存上，最后把这个内存地址封装到binder_write_read结构体中。Parcel作为一个基础的数据结构，和Binder相关类是可以解耦的，可以直接拿过来使用，我们可以根据需要对有耦合性的一些方法进行裁剪。

c++ Parcel类路径：frameworks/native/libs/binder/Parcel.cpp

jni Parcel类路径：frameworks/base/core/jni/android_os_Parcel.cpp

如何获取到BpBinder的mHandle句柄

具体流程参考Binder系列4—获取ServiceManager。

1、获取ServiceManager的mHandle句柄

defaultServiceManager()方法用来获取gDefaultServiceManager对象，gDefaultServiceManager是ServiceManager的单例。

sp defaultServiceManager() {
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
while (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast(
ProcessState::self()->getContextObject(NULL));
}
}
return gDefaultServiceManager;
}

getContextObject方法用来获取BpServiceManager对象（BpBinder），查看其定义：

sp ProcessState::getContextObject(const sp& /caller/) {
sp context = getStrongProxyForHandle(0);
return context;
}

可以发现，getStrongProxyForHandle是一个根据handle获取IBinder对象的方法，而这里handle的值为0，可以得知，ServiceManager的mHandle恒为0。

2、获取ActivityManager的mHandle句柄

获取ActivityManager的c++方法是：

sp binder = serviceManager->getService(String16(“activity”));

BpServiceManager.getService:

virtual sp getService(const String16& name) const {
sp svc = checkService(name);
if (svc != NULL) return svc;
return NULL;
}

BpServiceManager.checkService:

virtual sp checkService( const String16& name) const {
Parcel data, reply;
//写入RPC头
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
//写入服务名
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}

可以看到，CHECK_SERVICE_TRANSACTION这个binder调用是有返回值的，返回值会写到reply中，通过reply.readStrongBinder()方法，即可从reply这个Parcel对象中读取到ActivityManager的IBinder。每个Binder对象必须要有它自己的mHandle句柄，不然，transact操作是没办法进行的。所以，很有可能，Binder的mHandle的值是写到reply这个Parcel里面的。

看看reply.readStrongBinder()方法搞了什么鬼：

sp Parcel::readStrongBinder() const {
sp val;
readNullableStrongBinder(&val);
return val;
}
status_t Parcel::readNullableStrongBinder(sp* val) const {
return unflattenBinder(val);
}

调用到了Parcel::unflattenBinder方法，顾名思义，函数最终想要得到的是一个Binder对象，而Parcel中存放的是二进制的数据，unflattenBinder很可能是把Parcel中的一个结构体数据给转成Binder对象。

看看Parcel::unflattenBinder方法的定义：

status_t Parcel::unflattenBinder(sp* out) const {
const flat_binder_object* flat = readObject(false);
if (flat) {
…
sp binder =
ProcessState::self()->getStrongProxyForHandle(flat->handle);
}
return BAD_TYPE;
}

果然如此，从Parcel中可以得到一个flat_binder_object结构体，这个结构体重有一个handle变量，这个变量就是BpBinder中的mHandle句柄。

因此，在不依赖libbinder.so的情况下，我们可以自己组装数据发送给ServiceManager，进而获取到ActivityManager的mHandle句柄。

IPCThreadState是一个被Binder依赖的类，它是可以从源码中抽离出来为我们所用的。上一节中说到，Parcel类也是可以从源码中抽离出来的。

通过如下的操作，我们就可以实现ioctl获取到ActivityManager对应的Parcel对象reply：

Parcel data, reply;
// data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
// IServiceManager::getInterfaceDescriptor()的值是android.app.IActivityManager
data.writeInterfaceToken(String16(“android.app.IActivityManager”));
data.writeString16(String16(“activity”));
IPCThreadState::self()->transact(
0/ServiceManger的mHandle句柄恒为0/,
CHECK_SERVICE_TRANSACTION, data, reply, 0);

reply变量也就是我们想要的包含了flat_binder_object结构体的Parcel对象，再经过如下的操作就可以得到ActivityManager的mHandle句柄：

const flat_binder_object* flat = reply->readObject(false);
return flat->handle;

3、传输启动指定Service的Parcel数据

上一步已经拿到ActivityManger的mHandle句柄，比如值为1。这一步的过程和上一步类似，自己封装Parcel，然后调用IPCThreadState::transact方法传输数据，伪代码如下：

Parcel data;
// 把Service相关信息写到parcel中
writeService(data, packageName, serviceName, sdk_version);
IPCThreadState::self()->transact(
1/上一步获取的ActivityManger的mHandle句柄值是1/,
CHECK_SERVICE_TRANSACTION, data, reply,
1/TF_ONE_WAY/);

4、writeService方法需要做什么事情？

下面这段代码是Java中封装Parcel对象的方法：

Intent intent = new Intent();
ComponentName component = new ComponentName(context.getPackageName(), serviceName);
intent.setComponent(component);

Parcel mServiceData = Parcel.obtain();
mServiceData.writeInterfaceToken(“android.app.IActivityManager”);
mServiceData.writeStrongBinder(null);
mServiceData.writeInt(1);
intent.writeToParcel(mServiceData, 0);
mServiceData.writeString(null); // resolvedType
mServiceData.writeInt(0);
mServiceData.writeString(context.getPackageName()); // callingPackage
mServiceData.writeInt(0);

可以看到，有Intent类转Parcel，ComponentName类转Parcel，这些类在c++中是没有对应的类的。所以需要我们参考intent.writeToParcel/ComponentName.writeToParcel等方法的源码的实现，自行封装数据。下面这段代码就是把启动Service的Intent写到Parcel中的方法：

void writeIntent(Parcel &out, const char *mPackage, const char *mClass) {
// mAction
out.writeString16(NULL, 0);
// uri mData
out.writeInt32(0);
// mType
out.writeString16(NULL, 0);
// // mIdentifier
out.writeString16(NULL, 0);
// mFlags
out.writeInt32(0);
// mPackage
out.writeString16(NULL, 0);
// mComponent
out.writeString16(String16(mPackage));
out.writeString16(String16(mClass));
// mSourceBounds
out.writeInt32(0);
// mCategories
out.writeInt32(0);
// mSelector
out.writeInt32(0);
// mClipData
out.writeInt32(0);
// mContentUserHint
out.writeInt32(-2);
// mExtras
out.writeInt32(-1);
}

继续写Demo试一下

上面已经知道了怎么通过ioctl获取到ActivityManager，可以写demo试一下：

// 打开binder设备
int fd = open(“/dev/binder”, O_RDWR | O_CLOEXEC);
Parcel data, reply;
// data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
// IServiceManager::getInterfaceDescriptor()的值是android.app.IActivityManager
data.writeInterfaceToken(String16(“android.app.IActivityManager”));
data.writeString16(String16(“activity”));
IPCThreadState::self()->transact(
0/ServiceManger的mHandle句柄恒为0/,
CHECK_SERVICE_TRANSACTION, data, reply, 0);

const flat_binder_object *flat = reply->readObject(false);
if (flat) {
LOGD(“write_transact handle is:%llu”, flat->handle);
}else {
LOGD(“write_transact failed, error=%d”, status);
}

给IPCThreadState::transact加上一些日志，打印结果如下：

D/KeepAlive: BR_DEAD_REPLY
D/KeepAlive: write_transact failed, error=-32

reply中始终读不到数据。这是为什么？现在已经不报Invalid argument的错误了，说明Parcel数据格式可能没问题了。但是不能成功把数据写给ServiceManager，或者ServiceManager返回的数据不能成功写回来。

想到Binder是基于内存的一种IPC机制，数据都是对的，那问题就出在内存上了。这就要说到Binder基本原理以及Binder内存转移关系。

Binder基本原理：

Binder的Client端和Server端位于不同的进程，它们的用户空间是相互隔离。而内核空间由Linux内核进程来维护，在安全性上是有保障的。所以，Binder的精髓就是在内核态开辟了一块共享内存。

数据发送方写数据时，内核态通过copy_from_user()方法把它的数据拷贝到数据接收方映射(mmap)到内核空间的地址上。这样，只需要一次数据拷贝过程，就可以完成进程间通信。

由此可知，没有这块内核空间是没办法完成IPC通信的。Demo失败的原因就是缺少了一个mmap过程，以映射一块内存到内核空间。修改如下：

#define BINDER_VM_SIZE ((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2)
int mDriverFD = open(“/dev/binder”, O_RDWR | O_CLOEXEC);
mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

上面分享的字节跳动公司2021年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

【Android高级架构视频学习资源】

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

oid）**

总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

上面分享的字节跳动公司2021年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
[外链图片转存中…(img-XO3lSeRO-1712385364092)]

【Android高级架构视频学习资源】

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！