【Telephony】【SAR】Android设备辐射值回退需求Telephony实现（MTK）

小孤蓝课堂开课拉，现在是实践时间！
今天是开发课!!!
内含实践需求分析、开发过程！！！！
因为比较冷门所以简介长了点

一．Sar简介

  Specific Absorption Rate，简称SAR，即“比吸收率”或“电磁波吸收比值”。它是指生物体或物质每单位质量、单位时间内所吸收的电磁能量，其单位通常为W/kg或mW/g。在电子产品领域，如手机和无线网络设备在工作时会产生电磁辐射，SAR值用来评估这些设备对人体健康的影响。数值越大，表示对人体的影响越大；反之则影响较小。SAR的意义在于衡量单位质量的人体组织所吸收或消耗的电磁功率，从而评估电磁辐射可能给身体带来的潜在危害。
  简单的来说就是设备电磁辐射回退。国际市场上，部分国家对辐射强度都有严格的标准，项目想要出货必须完成认证。常见的标准是FCC（美国联邦通信委员会）和CE（欧洲共同体）
  此外，不同国家和地区可能还有自己的SAR标准或规定。例如，印度要求能用拨号暗码（*#07#）把当前设备的SAR认证值弹出。这些标准可能因地区、文化背景、技术水平等因素而有所不同。需要注意的是，SAR标准的具体内容和限值可能会随着技术的发展和研究的深入而有所调整。因此，建议定期关注相关标准和规定的更新情况，以获取最新的信息。
  SAR在软件实现上，有Cellular SAR、WiFi SAR等区分。因为涉及到的电子器件不同，所以软件需要监听的事件也不同，例如有些设备没有SarSensor 。我们Telephony一般负责Cellular SAR、Sensor SAR等，和Wifi RD配合完成，因为这块代码逻辑是在一个类中，区别只是事件和场景不同。要想实现设备降Sar需要从硬件到软件实现一整套完整流程，本文关注AP侧（Telephony）的相关实现。

二.降Sar职能划分

中大规模的企业，SAR认证需求一般是多个职能部门联合完成的，这个需求涉及到硬件、软件、认证职能部门，一般在需求基本实现后，在自研实验室验证pass才会送检。
硬件：射频、天线
软件：Telephony、WIFI、BSP、Modem

项目	Value
Telephony	根据场景流程图、功率表在framework实现场景事件监听和发送指令给底层执行Cellular SAR回退。
WIFI	根据场景流程图、功率表在framework实现场景事件监听和发送指令给底层执行WIFI SAR回退。
BSP	确认SWTP/SAR GPIO口，同步配置软件接口
Modem	修改SWTP AP侧参数，合入SWTP和SAR的patch
射频	1、频确认SWTP/SAR GPIO口，同步配置软件接口，GPIO口需要和实时原理图对应；2、确认SWTP/SAR对应的GPIO口给到BSP；3、根据天线需求配置modem主频回退NV；
天线	1、提供SAR场景流程图、功率Table表，给到软件；2、SAR功能实现方案以及硬件版本汇总;

三．Telephony实现降Sar

Telephony针监听不同的场景，触发不同的table表，通过AT命令与modem交互，最终完成射频天线的降Sar功能。这里重点实现两个功能：
1.根据天线团队提供的场景流程图，Telephony进行服务监听，触发不同table表。
2.通过table表，下发AT命令操纵降Sar。

整个SAR的核心类是SarControl.java，包含1个Handler发送AT命令、1个BroadcastReceiver监听状态。
该类为降Sar核心类，负责场景触发table及AT下发我们只需要将他放在framework层，根据不同需求，可以在AudioService或、PhoneWindowManager、TeleCom将他初始化。
下面我用一个实际的项目需求来讲解SarControl.java。这个需求场景较为简单，不需要关注sensor，属于较为简单的SAR需求

需求：根据连接状态、空口检测、听筒、热点等简单场景的SAR值回退，项目不带sensor。

1.根据天线提供的场景流程图，Telephony进行服务监听，触发不同table表。

我们分析流程图，我们需要在AudioService启动SarControl.java监听手机状态变化，然后开始执行SAR判定。这里的手机状态包含：

Intent.ACTION_BOOT_COMPLETED

WifiManager.WIFI_AP_STATE_CHANGED_ACTION

TelephonyIntents.ACTION_SIM_STATE_CHANGED

Intent.ACTION_SERVICE_STATE

TelephonyManager.ACTION_PHONE_STATE_CHANGED

Intent.ACTION_SCREEN_ON

TelephonyRegistry.ACTION_ANY_DATA_CONNECTION_STATE_CHANGED

SarControl.java创建一个广播，在广播过滤器中加上这些事件，当发生这些事件时，我们就需要进行SAR回退判定。

至于判定逻辑，可以看到流程图的逻辑很简单，几个if的事，并且telephony不需要关心包含回退具体值的table表。所以，我们重点难点是在监听场景上：
1）是否建立连接
2）是否空口检测
3）听筒是否打开
4）热点是否打开

1）是否建立连接

连接指的是电话连接、数据连接、卡1连接、卡2连接。并集，其中一个成立则为True
电话连接：

电话连接也就是Phone进入了通话状态。Phone的状态只有三种IDLE,OFFHOOK,RINGING。我们只需要执行这两个判定：判断TelephonyManager.EXTRA_STATE的当前值与这俩的比较结果
TelephonyManager.EXTRA_STATETelephonyManager.EXTRA_STATE_RINGING；
TelephonyManager.EXTRA_STATETelephonyManager.EXTRA_STATE_OFFHOOK；
通话的状态更细一些分为IDLE、DIALING、ACTIVE、HOLD、RINGING等等。OFFHOOK就包括了DIALING,ACTIVE,HOLD三种call状态。

数据连接：

数据连接有这几个状态
/** @hide */
@IntDef(prefix = {“DATA_”}, value = {
DATA_UNKNOWN,
DATA_DISCONNECTED,
DATA_CONNECTING,
DATA_CONNECTED,
DATA_SUSPENDED,
DATA_DISCONNECTING,
DATA_HANDOVER_IN_PROGRESS,
})
@Retention(RetentionPolicy.SOURCE)
public @interface DataState{}

我们可以执行这个判定： TelephonyManager的getDataState()函数返回值==TelephonyManager.DATA_CONNECTED判定数据状态是否连接。
也可以用TelephonyRegistry.ACTION_ANY_DATA_CONNECTION_STATE_CHANGED广播的意图intent.getStringExtra(“state”);函数获取数据状态

卡连接状态：

卡1卡2的区别只是Slot的区别，和sim卡本身没关系。我们用Intent.ACTION_SERVICE_STATE广播的意图intent.getExtras()去获得服务状态就可以获得卡服务状态：
ServiceState serviceState =ServiceState.newFromBundle(intent.getExtras());
serviceState.getVoiceRegState() == ServiceState.STATE_IN_SERVICE || serviceState.getDataRegState() == ServiceState.STATE_IN_SERVICE;
这个判定结果去结合卡槽SlotId判定，结果就能获得卡1连接、卡2连接的连接状态。
int slotId =ntent.getIntExtra(SubscriptionManager.EXTRA_SLOT_INDEX, 0);

2）是否空口检测

判断空口检测是否打开，这涉及到跨进程通信，一般我们用“共享内存”的形式。与驱动同事约定好一个RF_PATH，当空口检测时往文件写入参数，我们执行场景判定时读取文件参数就能获得空口检测状态，一般是一个保存0/1的文件。

3）听筒是否打开

用监听器和广播的方式判定听筒状态。 创建 private final AudioManager.OnAudioPortUpdateListener mAsOnAudioPortUpdateListener =new AudioManager.OnAudioPortUpdateListener() 监听器。
重写public void onAudioPatchListUpdate(AudioPatch[] patchList)方法获取earpiece状态。
在广播中监听听筒状态获取earpiece状态：
intentFilter.addAction(“com.android.server.OPEN_EARPIECE”);
intentFilter.addAction(“com.android.server.CLOSE_EARPIECE”);

4）热点是否打开

用WifiManager.WIFI_AP_STATE_CHANGED_ACTION广播的意图获取当前状态：
int wifiApState =intent.getIntExtra(WifiManager.EXTRA_WIFI_AP_STATE,WifiManager.WIFI_AP_STATE_FAILED);
然后对比wifiApState==WifiManager.WIFI_AP_STATE_ENABLED就能判定热点是否打开

拿到这些状态，在发送AT命令前选择表的最终逻辑就是：

if (mConnected) {
        if (mRfPort && mRfportEnable) {
            table = 1;
        } else if (mEarpiece) {
            table = 2;
        } else if (mHotspot) {
            table = 3;
        } else {
            table = 4;
        }
    }

2.通过table表，下发AT命令操纵降Sar。

发送AT命令需要用Handler发送，因为广播数量不好把控，需要创建消息队列来发送，否则有概率会阻塞Main线程，这在安卓是不允许的。
有两种方式来发送AT：

1)用AT+ERFTX命令

好处：
只需要配置一个供AP调用的ATCMD文件即可。所有场景的定义及降幅均在此文件中配置，简单易配置。不需要在射频modem中配置sar相关NV，不需开path和宏。
坏处：
AT+ERFTX这个CMD只支持到两天线，且MTK回复后续不会再维护。由于此AT指令中只定义了上/下天线对应降幅的位置(state0/1)，因此只适合TAS1.0。TAS2.0加 入左右天线 (state2等) ，无法使用此方法实现多出来的天线的降sar。

2）用AT+ERFIDX命令

AP侧根据不同场景去调用对应的index。不同index下不同频段的降幅在射频modem定义，以NV形式体现出来。
好处：
AP侧的实现方式更简单，只需要简单调用，不受TX天线个数的局限，不论TAS1.0/2.0只需确定在对应场景时，射频驱动中对应的INDEX配置为需要降SAR的值即可
坏处：
此方法需要在射频modem中配置相关文件，且需要打入patch及相应的宏。

目前新产品都是使用方式二（AT+ERFIDX）进行，上层不再需要维护table表，具体配置由modem来完成。
最终，我们Telephony通过监听场景结合流程图，在手机状态改变时向modem发送 “AT+ERFIDX”+ table;命令就可以完成Sar值回退。

四.总结

  到这里一个简单的场景需求就完成了，但是还有比较复杂的需求。
例如sar sensor节点，我们可以在上层通增加Keyevent来定义Sar sensor的远近从而反映其变化，这里需要bsp完成对应事件定义处理并提供相关Sar sensor的设备名称，从而实现对Sar Sensor功能实时监听监听处理的完整通路。之后同理，获取变化后发送AT命令+table给modem。
  还有一点补充的就是，需要定义一个宏控来控制这套监听机制开启和关闭，在特定环境下关闭SAR场景检测。一个项目出货不同国家要出两套判定标准，如FCC、CE等等，这些都能在这基础上控制。