Android sharedUserId引起的血案

前段时间遇见过这样一个问题，值得记一笔。

背景：

    我们原来在5.1设备上有一个32位的so库，系统进程直接使用该so库，因为当时系统也是32位的，没有出现问题，现在，我们切到了7.1的新64位平台，但是该so库我们没有源码，所以我们无法把该so编译为64位，也无法在64位系统进程中用32位的so库（反正我不知道怎么用），所以我们写了一个apk，单独运行在一个进程，被设置为32位apk，因为一些权限问题，该应用被设置sharedUserId为android.uid.system。

现象：

系统起来之后概率性出现，各种应用停止运行（Settings啊之类的），看log显示，这些apk都去32位的环境下找dex文件或者so文件。

分析：

我们系统的apk怎么会去32位的环境下找需要的文件呢？肯定是哪里出了问题，当时只是在运行过程中看日志分析，没有进展，突然灵机一动，应该去看看apk安装的日志，也就是开机log啊。果然发现了猫腻，打出了如下的log：

                        Slog.i(TAG, "Adjusting ABI for " + ps.name + " to " + adjustedAbi
                                + " (requirer="
                                + (requirer == null ? "null" : (requirer.pkg == null ? "null" : requirer.pkg.packageName))
                                + ", scannedPackage="
                                + (scannedPackage != null ? scannedPackage.packageName : "null")
                                + ")");

requirer.pkg为那个32位的apk，ps.name为系统中所有sharedUserId为android.uid.system，意味着其他apk根据了那个32位的apk的ABI而调整了自身的ABI，仔细看了看该段日志前后代码逻辑，发现，系统认为同一个sharedUserId的应用，primaryCpuAbi应该为一样的，妈的，这不坑爹吗？

解决方案：

知道了原因解决起来就很简单，针对那个应用的包名，把系统这套逻辑屏蔽了。