[RK 3399/RK 3328][Android 7.1.1]uid=systemアプリケーションが32ビットライブラリを強制的に使用し、デフォルトでodexを生成する場合、高概率性によりシステムアプリケーションSettingsなど(uid=systemアプリケーション)ライブラリエラーが見つからない
4729 ワード
テストプラットフォーム
Platform: RK3399 OS: Android 7.1.1
げんしょう
システム権限(uid=system)を有するapkを記述するが、第三者soが使用する、第三者が32ビットしかないため、appは32ビットsoのみを使用することを制限する.その後、起動時のおおよその確率で、Settings(または他のuid=systemアプリケーション、例えばKeyChain)に対応するodexファイル(クラス)が見つからず、エラーが発生し、logは以下のように報告されます.
私たちが直面している問題は、私たちが自分で作成したアプリケーションはシステムアプリケーションで、システムのsystemuidを使用しています.settingのuidと同じです.そして、私たちは32ビットapkで、settingは64ビットapkです.このように電源を入れると、libライブラリにsettingが届かないことがよくあります.対応するログは以下の通りです.
ぶんせき
システムコードを分析すると、7.1からシステムに新しい特性があることが分かった.同じuidのアプリケーションは同じlibアドレスを使用し、uid=systemの応用例である.lib 64を使用するとlib 64になり、libであればlibになり、32と64を混在させることはできません.32を指定するか64を指定するかは、最初に解析するuid=systemのアプリケーションを基準とするので、彼が最初に私たちのアプリケーションを解析すると、32ビットのlibを指定していることに気づき、他のuid=systemが実行すると、libの下で対応するクラスを探すだけですが、他はarm 64なので、クラスのエラーが見つからないという問題が発生します.
ソリューション
最良の態様は、当然、64ビットのライブラリ(態様1)を見つけるか、32ビットの部分を単独で1つのapkにカプセル化してaidlを介して対話する(態様2).ただし、シナリオ1.一部のサードパーティ製ライブラリでは32ビットしか64ビットが見つからないため、シナリオ2ができません.時々問題が発生するapkはソースコードが修正できないわけではないので、否定します.
では、残りの案3:
シナリオ3はodexを生成する際にapkからclassesを入れないことを意味する.dexが抽出するlibの下のodexが見つからない場合、apk中のclassesを解析することができる.dexは、エラーを報告することはない.
しかし、これも欠点があり、ファームウェアの体積が大きくなるので、他に解決する方法はないでしょう.
Platform: RK3399 OS: Android 7.1.1
げんしょう
システム権限(uid=system)を有するapkを記述するが、第三者soが使用する、第三者が32ビットしかないため、appは32ビットsoのみを使用することを制限する.その後、起動時のおおよその確率で、Settings(または他のuid=systemアプリケーション、例えばKeyChain)に対応するodexファイル(クラス)が見つからず、エラーが発生し、logは以下のように報告されます.
Process: com.android.keychain, PID: 1177
java.lang.RuntimeException: Unable to instantiate service com.android.keychain.KeyChainService: java.lang.ClassNotFoundException: Didn't find class "com.android.keychain.KeyChainService" on path: DexPathList[[zip file "/system/app/KeyChain/KeyChain.apk"],nativeLibraryDirectories=[/system/app/KeyChain/lib/arm64, /system/app/KeyChain/KeyChain.apk!/lib/armeabi-v7a, /system/lib, /vendor/lib, /system/lib, /vendor/lib]]
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3186)
at android.app.ActivityThread.-wrap5(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1577)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6157)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:802)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.android.keychain.KeyChainService" on path: DexPathList[[zip file "/system/app/KeyChain/KeyChain.apk"],nativeLibraryDirectories=[/system/app/KeyChain/lib/arm64, /system/app/KeyChain/KeyChain.apk!/lib/armeabi-v7a, /system/lib, /vendor/lib, /system/lib, /vendor/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:380)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3183)
at android.app.ActivityThread.-wrap5(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1577)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(Activity
私たちが直面している問題は、私たちが自分で作成したアプリケーションはシステムアプリケーションで、システムのsystemuidを使用しています.settingのuidと同じです.そして、私たちは32ビットapkで、settingは64ビットapkです.このように電源を入れると、libライブラリにsettingが届かないことがよくあります.対応するログは以下の通りです.
ぶんせき
システムコードを分析すると、7.1からシステムに新しい特性があることが分かった.同じuidのアプリケーションは同じlibアドレスを使用し、uid=systemの応用例である.lib 64を使用するとlib 64になり、libであればlibになり、32と64を混在させることはできません.32を指定するか64を指定するかは、最初に解析するuid=systemのアプリケーションを基準とするので、彼が最初に私たちのアプリケーションを解析すると、32ビットのlibを指定していることに気づき、他のuid=systemが実行すると、libの下で対応するクラスを探すだけですが、他はarm 64なので、クラスのエラーが見つからないという問題が発生します.
ソリューション
最良の態様は、当然、64ビットのライブラリ(態様1)を見つけるか、32ビットの部分を単独で1つのapkにカプセル化してaidlを介して対話する(態様2).ただし、シナリオ1.一部のサードパーティ製ライブラリでは32ビットしか64ビットが見つからないため、シナリオ2ができません.時々問題が発生するapkはソースコードが修正できないわけではないので、否定します.
では、残りの案3:
1. apk android.mk
LOCAL_DEX_PREOPT := nostripping
2./device/rockchip/rk3399/BoardConfig.mk,
DEX_PREOPT_DEFAULT := nostripping
シナリオ3はodexを生成する際にapkからclassesを入れないことを意味する.dexが抽出するlibの下のodexが見つからない場合、apk中のclassesを解析することができる.dexは、エラーを報告することはない.
しかし、これも欠点があり、ファームウェアの体積が大きくなるので、他に解決する方法はないでしょう.