Framework Service reads the value of Nvram and decides to open a different launcher

Framework Service reads the value of Nvram and decides to open different launchers

• Preface
• 1. Add nvram compilation to the framework
• 2. Modify the code
• • 1. Modify the logic of home intent
  • 2. Modify SE permissions
• Summarize

Foreword

The written value here is in NVram, and restoring the factory settings will not affect this value. It will be updated only by flashing;
Generally speaking, the intent of the home button to open the launcher is fixed. However, we can modify the logic of opening the home intent to open different launchers;
First understand the use of NvRam in the app layer. The use of NvRAM in the App layer.
And its use in uboot and kernel. MTK can modify the boot logo dynamically and restore the factory settings without restoring.

1. Add nvram compilation to the framework

diff --git a/alps/frameworks/base/Android.bp b/alps/frameworks/base/Android.bp
index 37bfc439aa..3e78c82846 100644
--- a/alps/frameworks/base/Android.bp
 + + + b/alps/frameworks/base/Android.bp
@@ -785,6 + 785,7 @@ java_defaults {<!-- -->
         "android.hardware.vibrator-V1.3-java",
         "android.hardware.wifi-V1.0-java-constants",
         "devicepolicyprotosnano",
 + "vendor.mediatek.hardware.nvram-V1.0-java",
     ],
 
     required: [
diff --git a/alps/frameworks/base/services/Android.bp b/alps/frameworks/base/services/Android.bp
index b08d1a8095..25ca50ed37 100644
--- a/alps/frameworks/base/services/Android.bp
 + + + b/alps/frameworks/base/services/Android.bp
@@ -36,6 + 36,7 @@ java_library {<!-- -->
         "services.usb",
         "services.voiceinteraction",
         "android.hidl.base-V1.0-java",
 + "vendor.mediatek.hardware.nvram-V1.0-java",
     ],
 
     libs: [

2. Modify code

1. Modify the logic of home intent

Android10 is in ActivityTaskManagerService.java, there is a little difference before 10. Just search where the getHomeIntent method is.
Note that private int mOffset=774; this value refers to the offset of the data storage location. How did the definition of mOffset come from the two articles in the preface?

diff --git a/alps/frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java b/alps/frameworks/base/services/core/java/com/android/ server/wm/ActivityTaskManagerService.java
index 7c39d29a70..3be814e23b 100755
--- a/alps/frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java
 + + + b/alps/frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java
@@ -298,6 + 298,8 @@ import java.util.List;
 import java.util.Locale;
 import java.util.Map;
 import java.util.Set;
 + import com.android.internal.util.HexDump;
 + import vendor.mediatek.hardware.nvram.V1_0.INvram;
 

@@ -5874,10 + 5876,46 @@ public class ActivityTaskManagerService extends IActivityTaskManager.Stub {<!-- -->
      Intent getHomeIntent() {<!-- -->
        Intent intent = new Intent(mTopAction, mTopData != null ? Uri.parse(mTopData) : null);
         intent.setComponent(mTopComponent);
         intent.addFlags(Intent.FLAG_DEBUG_TRIAGED_MISSING);
         if (mFactoryTest != FactoryTest.FACTORY_TEST_LOW_LEVEL) {<!-- -->
- intent.addCategory(Intent.CATEGORY_HOME);
 + //intent.addCategory(Intent.CATEGORY_HOME);
 + int launcherindex=readNvRAMData();
 + if(launcherindex==0){<!-- -->
 + intent.addCategory("android.intent.category.HOME_CLIFE");
 + }else{<!-- -->
 + intent.addCategory(Intent.CATEGORY_HOME);
 + }
         }
         return intent;
     }
 +
 + private final String NVTAG="NvRAMUtil";
 + private final String PRODUCT_INFO_FILENAME = "/mnt/vendor/nvdata/APCFG/APRDEB/PRODUCT_INFO";
 + private int mSize=1024;
 + private int mOffset=774;
 + public int readNvRAMData() {<!-- -->
 + int targets = 0;
 + try {<!-- -->
 + String buff = null;
 + INvram agent = INvram.getService();
 + Log.i(NVTAG, "readData from " + PRODUCT_INFO_FILENAME);
 + if (agent != null) {<!-- -->
 + buff = agent.readFileByName(PRODUCT_INFO_FILENAME, mSize);
 + }
 + byte[] buffArr = HexDump.hexStringToByteArray(buff.substring(0, buff.length() - 1));
 + byte[] dataArr=new byte[4];
 +
 + System.arraycopy(buffArr,mOffset,dataArr,0,4);
 + Log.i(NVTAG, "readData 1111: buffArr=" + Arrays.toString(dataArr));
 +
 + // targets = (dataArr[0] & amp; 0xff) | ((dataArr[1] << 8) & amp; 0xff00) | ((dataArr[2] << 24) >>> 8) | (dataArr [3] << 24);
 + targets = (dataArr[0] & amp; 0xff) | ((dataArr[1] << 8) & amp; 0xff00) | ((dataArr[2] << 24) >> 8 & amp; 0xff0000) | ( dataArr[3] << 24);
 +
 + Log.i(NVTAG, "readData: buffArr=" + Arrays.toString(dataArr) + ", targets == " + targets);
 + } catch (Exception e) {<!-- -->
 + Log.e(NVTAG, "readData exception:" + e.getLocalizedMessage());
 + e.printStackTrace();
 + }
 + return targets;
 + }

2. Modify SE permissions

The code is as follows (example):

diff --git a/alps/device/mediatek/mt8168/sepolicy/basic/system_server.te b/alps/device/mediatek/mt8168/sepolicy/basic/system_server.te
index 5e4c9eab44..7e458d60a2 100644
--- a/alps/device/mediatek/mt8168/sepolicy/basic/system_server.te
 + + + b/alps/device/mediatek/mt8168/sepolicy/basic/system_server.te
@@ -20,3 + 20,5 @@ allow system_server media_rw_data_file:file open;
 allow system_server media_rw_data_file:file create;
 allow system_server sdcardfs:file rw_file_perms;
 allow system_server sdcardfs:file create;
 + allow system_server nvram_agent_binder_hwservice:hwservice_manager find;
 + allow system_server nvram_agent_binder:binder call;

Summary

The written value here is in NVram. Restoring factory settings will not affect this value. It will be updated only by flashing.
The use of NvRam in the app layer The use of NvRAM in the App layer
And its use in uboot and kernel. MTK can modify the boot logo dynamically and restore the factory settings without restoring.