1

上周發(fā)的一篇文章《android 7.1 apk的systemuid和系統(tǒng)應(yīng)用Setting相同導(dǎo)致開(kāi)機(jī)找不到庫(kù)的問(wèn)題》，然后有個(gè)小伙伴找我討論了，覺(jué)得自己的腦洞了打開(kāi)了很多，所以針對(duì)這個(gè)問(wèn)題再次做一次總結(jié)，如果大家有好的建議也可以在文末留言。

2

先說(shuō)一個(gè)命令 adb shell dumpsys package p > dumpsys_p ，這個(gè)命令可以查看apk的一些狀態(tài)，包括apk屬于32位還是64位，保存成文件后查找里面對(duì)應(yīng)的包名，就可以看到對(duì)應(yīng)應(yīng)用的信息。

3

我們先是分析了出現(xiàn)問(wèn)題時(shí)候的Settings，我們用原來(lái)的固件復(fù)現(xiàn)問(wèn)題，在出現(xiàn)問(wèn)題的時(shí)候用上面的命令查看，發(fā)現(xiàn)Settings已經(jīng)變成了32位。

Package com.android.settings:
userId=1000
sharedUser=SharedUserSetting{a6835fb android.uid.system/1000}
pkg=Package{6d89bbd com.android.settings}
codePath=/system/priv-app/Settings
resourcePath=/system/priv-app/Settings
legacyNativeLibraryDir=/system/priv-app/Settings/lib
primaryCpuAbi=armeabi-v7a

4

上篇文章提到，我們報(bào)錯(cuò)是因?yàn)闆](méi)有找到庫(kù)文件，還有下面的日志引起32位和64位不匹配的原因。

PackageManager: Instruction set mismatch, PackageSetting{1e08467
com.xxxxxx.jjjjj.titket.oceanFlower/1000} requires arm whereas
PackageSetting{51ca86c android.rockchip.update.service/1000} requires
arm64 PackageManager: Instruction set mismatch, PackageSetting{1e08467
com.xxxxxx.jjjjj.titket.oceanFlower/1000} requires arm whereas
PackageSetting{992cb54 android/1000} requires arm64

我們的第一個(gè)嘗試是，直接去掉原來(lái)修改的兩個(gè)宏，然后在Setings安裝位置system/priv-app/xxx/目錄下面建立一個(gè)lib/arm64文件夾。這樣復(fù)測(cè)20次，沒(méi)有出現(xiàn)問(wèn)題。原因是，我們的apk，發(fā)現(xiàn)當(dāng)前安裝位置下面有l(wèi)ib文件夾，優(yōu)先從文件夾里去找?guī)?#xff0c;而且是lib/arm64說(shuō)明是64位的，讓Settings運(yùn)行在64位模式，我們的apk運(yùn)行在32位模式。

5

添加前面文章的兩個(gè)宏之后，在生成固件的apk里面多了一個(gè)class.dex，我們嘗試把這個(gè)class.dex放到原來(lái)的Settings里面，然后再壓縮把原來(lái)的Settings替換掉，這樣復(fù)測(cè)20次，也是沒(méi)有問(wèn)題。所以這個(gè)class.dex起作用了。

• rm /data/system/packages.xml

• 恢復(fù)出廠設(shè)置

• 測(cè)試20次沒(méi)有出現(xiàn)問(wèn)題。

然后再查看Setting的運(yùn)行模式

userId=1000
sharedUser=SharedUserSetting{842777 android.uid.system/1000}
pkg=Package{7785b91 com.android.settings}
codePath=/system/priv-app/Settings
resourcePath=/system/priv-app/Settings
legacyNativeLibraryDir=/system/priv-app/Settings/lib
primaryCpuAbi=armeabi-v7a

Seting變成了32位，就因?yàn)槲覀兗恿薱lass.dex的原因。

6

后面大神給我了一個(gè)補(bǔ)丁，用來(lái)解決這個(gè)問(wèn)題，補(bǔ)丁代碼如下，希望對(duì)有這方面問(wèn)題的同學(xué)有參考意義

diff?--git?a/services/core/java/com/android/server/pm/PackageManagerService.java?b/services/core/java/com/android/server/pm/PackageManagerService.java
index?12901ba..6d4e6fa?100755
---?a/services/core/java/com/android/server/pm/PackageManagerService.java
+++?b/services/core/java/com/android/server/pm/PackageManagerService.java
@@?-2572,7?+2572,7?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
//?NOTE:?We?ignore?potential?failures?here?during?a?system?scan?(like
//?the?rest?of?the?commands?above)?because?there's?precious?little?we
//?can?do?about?it.?A?settings?error?is?reported,?though.
-????????????????adjustCpuAbisForSharedUserLPw(setting.packages,?null?/*?scanned?package?*/,
+????????????????adjustCpuAbisForSharedUserLPw(setting.sameProcessPackages,?null?/*?scanned?package?*/,
false?/*?boot?complete?*/);
?????????????}

@@?-7222,12?+7222,18?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
?????}

private?static?String?fixProcessName(String?defProcessName,
-????????????String?processName,?int?uid)?{
-????????if?(processName?==?null)?{
-????????????return?defProcessName;
-????????}
-????????return?processName;
-????}
+????????String?processName,PackageSetting?ps)?{
+????????????String?returnName?=?processName;
+????????????if?(returnName?==?null)?{
+????????????????returnName?=??defProcessName;
+????????????}
+????????????if?(returnName!=null?&&?returnName.equals("system"))?{
+????????????????if?(ps!=null?&&?ps.sharedUser?!=?null)
+????????????????ps.sharedUser.addSameProcessPackage(ps);
+????????????}
+????????return?returnName;
+????????}
+????

private?void?verifySignaturesLP(PackageSetting?pkgSetting,?PackageParser.Package?pkg)
throws?PackageManagerException?{
@@?-8508,7?+8514,7?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
?????????pkg.applicationInfo.processName?=?fixProcessName(
?????????????????pkg.applicationInfo.packageName,
?????????????????pkg.applicationInfo.processName,
-????????????????pkg.applicationInfo.uid);
+????????????????pkgSetting);

if?(pkg?!=?mPlatformPackage)?{
//?Get?all?of?our?default?paths?setup
@@?-8774,7?+8780,7?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
for?(i=0;?i<N;?i++)?{
?????????????????PackageParser.Provider?p?=?pkg.providers.get(i);
?????????????????p.info.processName?=?fixProcessName(pkg.applicationInfo.processName,
-????????????????????????p.info.processName,?pkg.applicationInfo.uid);
+????????????????????????p.info.processName,(PackageSetting)pkg.mExtras);
?????????????????mProviders.addProvider(p);
?????????????????p.syncable?=?p.info.isSyncable;
if?(p.info.authority?!=?null)?{
@@?-8833,7?+8839,7?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
for?(i=0;?i<N;?i++)?{
?????????????????PackageParser.Service?s?=?pkg.services.get(i);
?????????????????s.info.processName?=?fixProcessName(pkg.applicationInfo.processName,
-????????????????????????s.info.processName,?pkg.applicationInfo.uid);
+????????????????????????s.info.processName,(PackageSetting)pkg.mExtras);
?????????????????mServices.addService(s);
if?((policyFlags&PackageParser.PARSE_CHATTY)?!=?0)?{
if?(r?==?null)?{
@@?-8853,7?+8859,7?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
for?(i=0;?i<N;?i++)?{
?????????????????PackageParser.Activity?a?=?pkg.receivers.get(i);
?????????????????a.info.processName?=?fixProcessName(pkg.applicationInfo.processName,
-????????????????????????a.info.processName,?pkg.applicationInfo.uid);
+????????????????????????a.info.processName,(PackageSetting)pkg.mExtras);
?????????????????mReceivers.addActivity(a,?"receiver");
if?((policyFlags&PackageParser.PARSE_CHATTY)?!=?0)?{
if?(r?==?null)?{
@@?-8873,7?+8879,7?@@?public?class?PackageManagerService?extends?IPackageManager.Stub?{
for?(i=0;?i<N;?i++)?{
?????????????????PackageParser.Activity?a?=?pkg.activities.get(i);
?????????????????a.info.processName?=?fixProcessName(pkg.applicationInfo.processName,
-????????????????????????a.info.processName,?pkg.applicationInfo.uid);
+????????????????????????a.info.processName,(PackageSetting)pkg.mExtras);
?????????????????mActivities.addActivity(a,?"activity");
if?((policyFlags&PackageParser.PARSE_CHATTY)?!=?0)?{
if?(r?==?null)?{
diff?--git?a/services/core/java/com/android/server/pm/SharedUserSetting.java?b/services/core/java/com/android/server/pm/SharedUserSetting.java
old?mode?100644
new?mode?100755
index?06e020a..01897fb
---?a/services/core/java/com/android/server/pm/SharedUserSetting.java
+++?b/services/core/java/com/android/server/pm/SharedUserSetting.java
@@?-31,6?+31,7?@@?final?class?SharedUserSetting?extends?SettingBase?{
int?uidPrivateFlags;

final?ArraySet<PackageSetting>?packages?=?new?ArraySet<PackageSetting>();
+????final?ArraySet<PackageSetting>?sameProcessPackages?=?new?ArraySet<PackageSetting>();

final?PackageSignatures?signatures?=?new?PackageSignatures();

@@?-66,7?+67,11?@@?final?class?SharedUserSetting?extends?SettingBase?{
?????????????}
?????????}
?????}
-
+????
+????void?addSameProcessPackage(PackageSetting?packageSetting)?{
+????????sameProcessPackages.add(packageSetting);
+????}
+????????
void?addPackage(PackageSetting?packageSetting)?{
if?(packages.add(packageSetting))?{
?????????????setFlags(this.pkgFlags?|?packageSetting.pkgFlags);

7

參考我之前的文章
還有一些嘗試方法還沒(méi)有論證，喜歡研究的同學(xué)可以繼續(xù)跟進(jìn)
至于為何有同一個(gè)uid需要運(yùn)行位數(shù)一致，大神找到了這樣的解釋

Adjust instruction sets for shared UID apps.

Since shared UID apps are run in the same process,
we'll need to make sure they're compiled for the same
instruction set.

總結(jié)

以上是生活随笔為你收集整理的android 7.1 apk的systemuid相同导致问题[2]的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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