New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On x86_64 installs toybox_arm #745

Closed
LVware opened this Issue Feb 14, 2017 · 11 comments

Comments

2 participants
@LVware

LVware commented Feb 14, 2017

Info from debug log:

1487098476079 I/Debug: F: VERSIONNAME:4.6.2; VERSIONCODE:40602
1487098476092 D/Debug: ro.build.version.sdk=22
1487098476095 D/Debug: ro.build.version.release=5.1
1487098476095 D/Debug: ro.build.version.security_patch=2017-02-01
1487098476100 D/Debug: ro.product.model=MI PAD 2
1487098476100 D/Debug: ro.product.brand=Xiaomi
1487098476101 D/Debug: ro.product.board=latte
1487098476102 D/Debug: ro.product.cpu.abi=x86_64
1487098476102 D/Debug: ro.product.cpu.abilist=x86_64,x86,armeabi-v7a,armeabi,arm64-v8a
1487098476102 D/Debug: ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi
1487098476103 D/Debug: ro.product.cpu.abilist64=x86_64,arm64-v8a
...
1487098558627 I/SDMContext: RootContext: RootContext(rootState=ROOTED
1487098558627 D/SDMContext: Initialising SDMBox
1487098558643 D/BinaryInstaller: Setting up...
1487098558646 D/BinaryInstaller: Trying module InternalModule to setup toybox_sdm
1487098558647 D/BinaryExtractor: Architectures: Build.CPU_ABI=arm64-v8a,Build.CPU_ABI2=x86_64,Build.SUPPORTED_ABIS=[x86_64, x86, armeabi-v7a, armeabi, arm64-v8a],Build.SUPPORTED_32_BIT_ABIS=[x86, armeabi-v7a, armeabi],Build.SUPPORTED_64_BIT_ABIS=[x86_64, arm64-v8a]
1487098558649 D/BinaryExtractor: Raw architecture is [arm64-v8a] detected as [ARM]
1487098558650 I/BinaryExtractor: Extracting binary for arc ARM to path /data/data/eu.thedarken.sdm/cache/toybox_arm
1487098558650 D/BinaryExtractor: Checking current /data/data/eu.thedarken.sdm/cache/toybox_arm availability...
1487098558656 D/BinaryExtractor: Binary /data/data/eu.thedarken.sdm/cache/toybox_arm doesn't exist yet
1487098558656 D/BinaryExtractor: Copying new binary...
1487098558675 D/BinaryExtractor: Binary has been successfully created.
@d4rken

This comment has been minimized.

Owner

d4rken commented Feb 14, 2017

Does SD Maid still install a working toybox after that?
If the ARM one doesn't work the other ones should be tried too.

Can you attach a longer log? I'd like to see how SD Maid proceeds. Basically all logging until SDMBoxSource: .

It's a bit weird though that ro.product.cpu.abi=x86_64 but SD Maid tries BinaryExtractor: Raw architecture is [arm64-v8a] as first architecture. Will look into that.

@d4rken d4rken added the bug label Feb 14, 2017

@d4rken d4rken added this to the Next Tasks milestone Feb 14, 2017

@LVware

This comment has been minimized.

LVware commented Feb 14, 2017

SD Maid working fine with toybox_arm.
I noticed that the architecture is not correctly recognized in some applications without libraries.
For example, with libraries:
root@latte:/ # dumpsys activity p org.wikipedia |grep Abi
requiredAbi=x86_64 instructionSet=x86_64
root@latte:/ # dumpsys activity p com.rarlab.rar |grep Abi
requiredAbi=x86 instructionSet=x86
But:
root@latte:/ # dumpsys activity p eu.thedarken.sdm |grep Abi
requiredAbi=x86_64 instructionSet=null

@d4rken

This comment has been minimized.

Owner

d4rken commented Feb 14, 2017

SD Maid working fine with toybox_arm.

Are you sure it's using the ARM one? That's why I was interested in a longer log. Because SD Maid will try all other architectures if the initially tested one does not work.

And if the ARM one works too, then I wonder, would the X86 version perform better?

@LVware

This comment has been minimized.

LVware commented Feb 14, 2017

Can you attach a longer log?

sdmaid.txt

@d4rken

This comment has been minimized.

Owner

d4rken commented Feb 14, 2017

SD Maid seems to be happy with the ARM binary.

1487098559301 D/Binary:InternalSetupModule: Working architecture: ARM
1487098559302 D/Binary:InternalSetupModule: InternalModule (stage1): AppletSource(compat=USER, base=/data/data/eu.thedarken.sdm/files/toybox_sdm, type=INTERNAL, version=toybox 0.7.2-37-g109a28b8a749, appletCount=20)

The supported ABI preference order puts x86_64 and x86 before that though:

Build.SUPPORTED_ABIS=[x86_64, x86, armeabi-v7a, armeabi, arm64-v8a]

I just checked the code and SD Maid just uses Build.CPU_ABI to determine compatibility, likely because Build.SUPPORTED_ABIS required Lollipop. But I see no reason why we can't just add an if-check, such that on API 21 Build.SUPPORTED_ABIS is used which would in your case mean, SD Maid would have tried the x86 binary. Assuming that the device uses some kind of compatibility mode to support ARM, performance could be better...

If you want, send me a quick mail to support and I'll give you a test version with the change and you could let me know how that performs, and maybe a little log to confirm the behavior 😉 .

@d4rken d4rken added the enhancement label Feb 14, 2017

@d4rken d4rken modified the milestones: v4.6.3, Next Tasks Feb 14, 2017

@LVware

This comment has been minimized.

LVware commented Feb 15, 2017

Some applications (.apk) have executable binaries as lib/arch/libXXXXX.so.
Installation of such executable binaries as libraries takes place correctly.
Why are you doing otherwise?

@d4rken

This comment has been minimized.

Owner

d4rken commented Feb 15, 2017

Because toybox is not a program library, but a set of command line applets (e.g. find, stat), that SD Maid has to supply and setup to be able to reliably run shell commands on different devices.

There is no official support to install such binary executables correct (especially such that work with root), thus SD Maid requires it's own setup routine.

I've made the change I described above for v4.6.3. If you would like to help me test it, send me a mail.

@d4rken d4rken closed this Feb 15, 2017

@d4rken

This comment has been minimized.

Owner

d4rken commented Feb 15, 2017

On unrooted devices the setup of toybox/busybox is fairly straight forward (basically just copying the right into into the private files folder and setting permission), but if the binary is supposed to be used with root permission, THEN it gets difficult, especially on Samsung devices ...

Anyways, thanks the for logfile, I think this change will be an improvement and I would not have spotted this detail without you (don't have an x86 Android device at the moment, hmm though maybe the Chromebook I have could be X86...).

@LVware

This comment has been minimized.

LVware commented Feb 15, 2017

little log to confirm the behavior

sdmaid_logfile_1487120791076.txt

@d4rken

This comment has been minimized.

Owner

d4rken commented Feb 15, 2017

Perfect!

1487120873277 D/BinaryExtractor: Preferred architecture: raw=x86_64, detected=X86. Test order: [X86, MIPS, ARM].

Exchange and cleanup of the ARM binary works nicely too.

And SD Maid is happy with the X86 binary:

1487120873720 D/Binary:InternalSetupModule: Working architecture: X86
1487120873720 D/Binary:InternalSetupModule: InternalModule (stage1): AppletSource(compat=USER, base=/data/data/eu.thedarken.sdm/files/toybox_sdm, type=INTERNAL, version=toybox 0.7.2-37-g109a28b8a749, appletCount=20)

Did you notice any performance difference during scans?

@LVware

This comment has been minimized.

LVware commented Feb 15, 2017

Did you notice any performance difference during scans?

Excellent! Now faster ~3 times!
Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment