MTK NVRAM的读写

vendor/mediatek/proprietary/external/nvram

Android8.0以前,是通过AIDL的方式去获取一个名为【NvRAMAgent】的服务,然后通过该服务调用相关接口进行读写,获取NVRAM服务的方式如下:

IBinder binder = ServiceManager.getService("NvRAMAgent");
NvRAMAgent agent = NvRAMAgent.Stub.asInterface(binder);

读写方式如下:

fid = getProductInfoLid(); //这里获取SN的lid
byte[] ret = agent.readFile(fid); //通过lid去读取产品SN
agent.writeFile(fid, ret); //向NVRAM中写入SN

Android8.0以前,向NVRAM中读写SN或者MAC地址等信息时,一般是通过LID的方式,LID的值是在native中定义的。可以通过一个native函数获取到SN或者MAC地址对应的LID号,然后再进行读写。
LID号可以简单理解为SN或者MAC地址在NVRAM中的地址。

Android9.0 NVRAM的读写方式

到了Android8.0之后(这里以Android9.0系统为例),NVRAM的读写方式已经变更,不再通过AIDL去获取NVRAM服务,然后进行读写。而是通过HIDL的方式去获取服务来进行读写,方法如下:

import vendor.mediatek.harware.nvram.V1_0.INvram;

INvram agent = INvram.getService();

读写方法、

import com.android.internal.util.HexDump;
//读取:
String buffer = agent.readFileByName(path,size);
//size读取多长的数据,处理数据要注意直接通过字符串getByte获取的长度
//会是size的两倍+1(size是有效大小,根据Nvram存储的数据结构决定)
//+1是因为字符串带有结束符

//写入:
byte[] buff = HexDump.hexStringToByteArray(buffer.subString(0,buffer.length() - 1);
ArrayList dataArray = new ArrayList(size);

//修改buff数组中某一个字节的数据,然后重新写入到Nvram:
buff[index] = 0xff;
//將修改后的字节数组存到Array中
for(int index = 0; index < size; index ++) {
    dataArray.add(index,new Byte(buff[index]))
}
//最后需要:
agent.writeFileByNamevec(path,size,dataArray);

可以看到,Android8.0前后,NVRAM读写的不同点如下:
1.获取NVRAM服务的方式不一样,一个是AIDL,一个是HIDL;
2.NVRAM服务的接口不一致,一个是通过LID号的方式来进行读写,一个是通过节点的方式来进行读写;

这里需要注意的是,调用NvRam的新读写方法,这里要在Android.mk中新增依赖库,否则会编译不通过:

LOCAL_STATIC_JAVA_LIBRARIES += \
vendor.mediatek.hardware.nvram-V1.0-java-static

上层如何使用NVRAM接口

Android9.0 NVRAM的接口在上一节已经大概介绍,细心的朋友已经注意到,新的NVRAM接口是通过节点方式来读写的,那么这个节点在哪里呢?节点路径如下:

/vendor/nvdata/APCFG/APRDEB/WIFI  //wifi mac 地址
/VENDOR/nvdata/APCFG/APRDEB/BT_Addr //蓝牙 mac地址
/VENDOR/nvdata/APCFG/APRDEB/PRODUCT_INFO //SN号

调用如上接口,传入以上路径,就可以读写SN号和MAC地址。

但是,这里要说一个比较坑的事。那就是,如果通过这种方法去读写SN号,那么系统重启之后,SN号并没有更新成我们所烧录的那个SN号。
这是因为在MTK Android9.0中,有两种方式读写SN号:客户应用自己写或者通过MTK烧录工具烧写。专门提供给应用层读写的,路径就是如上提供的,但这个SN号读写之后并不会被系统所识别,也就是说不会被写入到序列号相关的属性中,如ro.serialno。另外一种通过烧录工具写入的,写入的地方为/dev/pro_info,重启后,这个可以被系统识别。

那如果即想要实现上层读写SN号,又能够被系统识别,那能否做到呢?答案当然是YES。
实现上层读写SN,系统也能识别,要想系统能够识别,则PRODUCT_INFO就不能出现,可以通过如下的宏来进行配置:

MTK_PRODUCT_INFO_SUPPORT = yes
则表示支持MTK的sn号烧录工具进行读写,然后该SN号可以在LK的时候被读出来,最后在init.cpp中赋值给ro.serial属性;
但这种配置无法支持应用对PRODUCT_INFO进行读写。


MTK_PRODUCT_INFO_SUPPORT = no
这种则表示支持应用对PRODUCT_INFO进行读写,但不支持MTK的sn号烧录工具读

https://www.cnblogs.com/guanxinjing/p/16869583.html
https://blog.csdn.net/u012932409/article/details/110393582
https://blog.csdn.net/qq_15347925/article/details/121682385
https://blog.csdn.net/u012932409/article/details/113172535

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注