在測試CTS Verifier測試的時候，有一項(xiàng)為開發(fā)者選項(xiàng)"OEM unlocking"功能，測試的時候需要人為進(jìn)行判斷是否成功。
測試此項(xiàng)前，需要執(zhí)行如下動作：

adb shell settings put global hidden_api_policy 1adb install -r -g CtsVerifier.apkadb install -r -t CtsEmptyDeviceOwner.apkadb shell dpm set-device-owner com.android.cts.emptydeviceowner/.EmptyDeviceAdmin

然后進(jìn)入開發(fā)者選項(xiàng)，查看OEM unlocking選項(xiàng)后面，是否會彈出一個“！”的圖標(biāo)，點(diǎn)擊會彈出一個動畫框，能否彈出對話框是根據(jù)設(shè)備是否已lock來判斷的。在bootloader中執(zhí)行fastboot flashing lock后，此項(xiàng)就可以通過了。

查看lock和unlocked時的系統(tǒng)屬性，
$ getprop |grep lock
[cache_key.is_user_unlocked]: [8110559973390150548]
[ro.boot.flash.locked]: [1]
[ro.boot.vbmeta.device_state]: [locked]
[ro.frp.pst]: [/dev/block/bootdevice/by-name/frp]
[ro.oem_unlock_supported]: [1]
[sys.oem_unlock_allowed]: [1]

$ getprop |grep lock
[cache_key.is_user_unlocked]: [8110559973390150548]
[ro.boot.flash.locked]: [1]
[ro.boot.vbmeta.device_state]: [locked]
[ro.frp.pst]: [/dev/block/bootdevice/by-name/frp]
[ro.oem_unlock_supported]: [1]
[sys.oem_unlock_allowed]: [0]

---

帶著這個問題，我們看一下OEM unlocking的內(nèi)容，主要是根據(jù)opengrok跟一下代碼的調(diào)用過程，內(nèi)容如下：

settings層=== EnableOemUnlockSettingWarningDialog.java onClick host.onOemUnlockDialogConfirmed(); |DevelopmentDashboardFragment.java onOemUnlockDialogConfirmed() @Override public void onOemUnlockDialogConfirmed() {final OemUnlockPreferenceController controller = getDevelopmentOptionsController(OemUnlockPreferenceController.class);controller.onOemUnlockConfirmed(); } |OemUnlockPreferenceController.java onOemUnlockConfirmed() public void onOemUnlockConfirmed() {mOemLockManager.setOemUnlockAllowedByUser(true); } |framework層=== OemLockManager.java setOemUnlockAllowedByUser mService.setOemUnlockAllowedByUser | IOemLockService.aidl setOemUnlockAllowedByUser(boolean allowed) | OemLockService.java setOemUnlockAllowedByUser(boolean allowedByUser)@Overridepublic void setOemUnlockAllowedByUser(boolean allowedByUser) {if (ActivityManager.isUserAMonkey()) {// Prevent a monkey from changing thisreturn;}enforceManageUserOemUnlockPermission();enforceUserIsAdmin();final long token = Binder.clearCallingIdentity();try {if (!isOemUnlockAllowedByAdmin()) {throw new SecurityException("Admin does not allow OEM unlock");}if (!mOemLock.isOemUnlockAllowedByCarrier()) {throw new SecurityException("Carrier does not allow OEM unlock");}mOemLock.setOemUnlockAllowedByDevice(allowedByUser);setPersistentDataBlockOemUnlockAllowedBit(allowedByUser);} finally {Binder.restoreCallingIdentity(token);}}/*** Always synchronize the OemUnlockAllowed bit to the FRP partition, which* is used to erase FRP information on a unlockable device.*/private void setPersistentDataBlockOemUnlockAllowedBit(boolean allowed) {final PersistentDataBlockManagerInternal pdbmi= LocalServices.getService(PersistentDataBlockManagerInternal.class);// if mOemLock is PersistentDataBlockLock, then the bit should have already been setif (pdbmi != null && !(mOemLock instanceof PersistentDataBlockLock)) {Slog.i(TAG, "Update OEM Unlock bit in pst partition to " + allowed);pdbmi.forceOemUnlockEnabled(allowed);}}|HW層=== android\hardware\interfaces\oemlock\1.0\IOemLock.hal setOemUnlockAllowedByDevice(bool allowed) generates (OemLockStatus status) | android/external/libese/esed/OemLock.cpp OemLock::setOemUnlockAllowedByDevice(bool allowed)

看代碼實(shí)現(xiàn)，此項(xiàng)應(yīng)該是留給oem廠商進(jìn)行定制使用的，開關(guān)打開和關(guān)閉主要是操作FRP分區(qū)，這個分區(qū)一般是GMS包版本會用到，比如GMS開機(jī)向?qū)е休斎氲挠脩糍~號等信息，都是存在FRP分區(qū)中。
當(dāng)用戶在設(shè)置中手動執(zhí)行恢復(fù)出廠設(shè)置時，在Recovery中一般會清除掉FRP分區(qū)信息。用戶執(zhí)行這個恢復(fù)出廠設(shè)置動作是“可信的”，可以清除FRP分區(qū)。
但是當(dāng)其他形為，比如直接通過命令如adb reboot recovery等或其他途徑進(jìn)入到recovery，是不會清除掉FRP分區(qū)的，開機(jī)進(jìn)入到GMS開機(jī)向?qū)Ы缑?#xff0c;還是需要用戶輸入賬號等信息的。而且我們這里的oem lock上鎖仍然是有效的，數(shù)據(jù)沒有被清除掉。

那么oem unlocking數(shù)據(jù)是存在哪了呢？
看代碼是存在了FRP分區(qū)的最后一個block的最后一個BIT比特位上，那是否真是如此呢？
我們可以將FRP分區(qū)通過dd命令導(dǎo)出來看一下，命令如下：

dd if=/dev/block/bootdevice/by-name/frp of=/data/data/1.data

在lock和unlock的狀態(tài)下，分別去dd一下，看下兩者有什么不同，下面是我的dd后的效果圖：

而且下面兩句都是往FRP分區(qū)的最后一個bit位操作，只是一個是hal對象的方式，一個是通過PersistentDataBlockManagerInternal API接口去操作的；hal的方式留出來是為了將來廠商進(jìn)行定制使用。

OemLockService.java setOemUnlockAllowedByUser(boolean allowedByUser)@Overridepublic void setOemUnlockAllowedByUser(boolean allowedByUser) { ...mOemLock.setOemUnlockAllowedByDevice(allowedByUser);setPersistentDataBlockOemUnlockAllowedBit(allowedByUser);}

我的理解大概就是這樣，僅供參考。

總結(jié)

以上是生活随笔為你收集整理的android OEM unlocking分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。