bootloop: signal 6 (SIGABRT), code -6 / Abort message: 'art/runtime/art_method.cc:532] Check failed: !IsFastNative()

[eos4git]

Hello, I am running into a constant bootloop on my device (E6853 Sony Xperia Z5 Premium, Linux version 3.10.84-perf-gf38969a, 32.2.A.0.305 standard Sony ROM firmware) which ends with the flashing of the red LED and a distorted screen display. The logcat can be downloaded here: https://1drv.ms/u/s!AsRNfkaVsoNauX3i6qBmIYf4ICqU and I am also attaching it here: liveboot.zip

My device in its present configuration runs fine with the framework installed up to version 85 (SDK23). The issue occurs regardless of any module, with all caches purged etc. Is this perhaps also connected to the announced issue with the services.odex in certain Sony ROMs? If not, please let me know if additional information would be of any help to you or if you would like me to run certain tests on my device.

Many thanks in advance for your help. Your work is greatly appreciated!

[rovo89]

The crash occurs in /vendor/lib/libxposed_safemap.so. But even though it sounds like it's related to Xposed, but it's definitely not part of the official framework. I have never heard about this file, do you have any ideas where it's coming from?

[eos4git]

Hmm. Sorry, no idea and Google has nothing to say about this module as well. :-( I am attaching it here though. Could you please risk a peek to see if it seems familiar after all? Thank you! libxposed_safemap.zip

Also, can I somehow unload it to see what happens then? Could this be some sort of virus or trojan installed by a malicious application masquerading as part of the Xposed framework?

[rovo89]

I can't see much in the file, just one thing I noticed: C:\Android\android-ndk-r10e\sources\... It's unusual to compile system native libraries on Windows, and vendors also would't compile this against the NDK but as part of the platform (AOSP). That doesn't necessarily mean it's a virus (didn't seevany suspecious strings), but it's at least strange.

By the way, this is also very strange:

I/Xposed  ( 1578): -----------------
I/Xposed  ( 1578): Starting Xposed version 87, compiled for SDK 23
I/Xposed  ( 1578): Device: E6853 (Sony), Android version 6.0.1 (SDK 23)
I/Xposed  ( 1578): ROM: 32.2.A.0.305
I/Xposed  ( 1578): Build fingerprint: Sony/E6853/E6853:6.0.1/32.2.A.0.305/724807262:user/release-keys
I/Xposed  ( 1578): Platform: arm64-v8a, 64-bit binary, system server: yes
I/Xposed  ( 1578): SELinux enabled: yes, enforcing: yes
I/Xposed  ( 1578): -----------------
I/Xposed  ( 1578): Added Xposed (/system/framework/XposedBridge.jar) to CLASSPATH
D/XposedStartupMarker( 1578): Current time: 1480311753, PID: 1578
I/Xposed  ( 1578): -----------------
I/Xposed  ( 1578): Starting Xposed version 86, compiled for SDK 23
I/Xposed  ( 1578): Device: E6853 (Sony), Android version 6.0.1 (SDK 23)
I/Xposed  ( 1578): ROM: 32.2.A.0.305
I/Xposed  ( 1578): Build fingerprint: Sony/E6853/E6853:6.0.1/32.2.A.0.305/724807262:user/release-keys
I/Xposed  ( 1578): Platform: arm64-v8a, 64-bit binary, system server: yes
I/Xposed  ( 1578): SELinux enabled: yes, enforcing: yes

It's loading Xposed twice, once with version 87 and once with version 86, both for the same process. I don't see a way how this situation could occur if you were using the official framework ZIPs. I suggest you review the ZIPs that you have flashed... and maybe also the apps you have installed recently, especially ones with root access.

Oh, and one more thing: The log also mentions /vendor/lib/libart.so. That library is usually loaded from /system/lib/.

[eos4git]

Again, many thanks for your time and effort. However, I am completely at a loss for words here. I am in fact using official framework ZIPs only, always have. Moreover, I have tried various ways of installing those and presently I am actually using the latest installer app (v3.11). There, I have also tried both options: installing directly and via Recovery. Also, I had to use the uninstaller a couple of times so far to recover from the boot loop. I would have imagined, it got rid of all artefacts. On a side note, I have been running this configuration for quite some time now updating the ROM a month ago. Because it was the same Android version (6.0.1 -> 6.0.1) I did not bother doing a complete wipe / factory reset. After the update, I had to re-install the framework though with the new installer (v3.11) which brought me where I am today.

All this said, what would you recommend me to do? Shall I give it a try and disable those modules or does a factory reset seem imminent to you now?

[rovo89]

As I said - this doesn't look like an offical Xposed version, as it's installed in /vendor. The uninstaller doesn't clean up there because the installer wouldn't put stuff there.

It would definitly be interesting to know how these files got there. Maybe further files in /vendor can give a hint about that. Anyway, flashing the stock ROM over your current installation (especially over the vendor partition) might fix it.

[eos4git]

I understand what you are saying, but I did install a stock ROM. That is the weird thing about all this. Here is the folder structure for /vendor

shell@E6853:/ $ ls -laF /vendor
lrwxrwxrwx root root 1970-06-07 19:45 app -> /system/vendor/app drwxr-xr-x root root 1970-06-07 19:45 bin lrwxrwxrwx root root 1970-06-07 19:45 camera -> /system/vendor/camera lrwxrwxrwx root root 1970-06-07 19:45 etc -> /system/vendor/etc lrwxrwxrwx root root 1970-06-07 19:45 firmware -> /system/vendor/firmware drwxr-xr-x root root 2016-11-01 20:56 framework drwxr-xr-x root root 1970-06-07 19:45 lib drwxr-xr-x root root 1970-06-07 19:45 lib64 lrwxrwxrwx root root 1970-06-07 19:45 media -> /system/vendor/media lrwxrwxrwx root root 1970-06-07 19:45 overlay -> /system/vendor/overlay lrwxrwxrwx root root 1970-06-07 19:45 pittpatt -> /system/vendor/pittpatt lrwxrwxrwx root root 1970-06-07 19:45 qcril.db -> /system/vendor/qcril.db -rw-r--r-- root root 42 2016-11-01 20:56 xposed.prop

[rovo89]

Any idea what you installed on 1st of November at 20:56? That's when xposed.prop and the framework folder were created.

Regarding recoverying: I'm only used to the way Google's updates work, and those wipe any existing content from the partitions as soon as you reflash it. Maybe you have to wipe /vendor manually.

[eos4git]

That was when I installed the ROM. Could it be that this vendor partition is specific to certain providers which I understand can adapt stock ROMs to inject their own apps? I can boot into Recovery and simply delete all of the folder's contents to see what happens. I have got a fresh full backup from yesterday anyway.

I have meanwhile risked a peek in some of the sub-folders such as this one: shell@E6853:/ $ ls -laF /vendor/camera/
drwxr-xr-x root shell 2016-09-16 04:29 LGI05BN0 -rw-r--r-- root root 12480 2016-09-16 04:29 LGI05BN0_IMX241.dat drwxr-xr-x root shell 2016-09-16 04:29 SEM05BN0 -rw-r--r-- root root 12480 2016-09-16 04:29 SEM05BN0_IMX241.dat drwxr-xr-x root shell 2016-09-16 04:29 SOI25BS0 -rw-r--r-- root root 38 2016-09-16 04:29 SOI25BS0_BU64747GWZ.dat -rw-r--r-- root root 481 2016-09-16 04:29 SOI25BS0_BU64747GWZ_XCF.dat -rw-r--r-- root root 3079 2016-09-16 04:29 SOI25BS0_BU64747GWZ_XFW.dat -rw-r--r-- root root 85788 2016-09-16 04:29 SOI25BS0_IMX300.dat drwxr-xr-x root shell 2016-09-16 04:29 SOI25BS1 -rw-r--r-- root root 38 2016-09-16 04:29 SOI25BS1_BU64747GWZ.dat -rw-r--r-- root root 481 2016-09-16 04:29 SOI25BS1_BU64747GWZ_XCF.dat -rw-r--r-- root root 3079 2016-09-16 04:29 SOI25BS1_BU64747GWZ_XFW.dat -rw-r--r-- root root 84672 2016-09-16 04:29 SOI25BS1_IMX300.dat drwxr-xr-x root shell 2016-09-16 04:29 SOI25BS2 -rw-r--r-- root root 38 2016-09-16 04:29 SOI25BS2_BU64747GWZ.dat -rw-r--r-- root root 481 2016-09-16 04:29 SOI25BS2_BU64747GWZ_XCF.dat -rw-r--r-- root root 3079 2016-09-16 04:29 SOI25BS2_BU64747GWZ_XFW.dat -rw-r--r-- root root 84672 2016-09-16 04:29 SOI25BS2_IMX300.dat drwxr-xr-x root shell 2016-09-16 04:29 SOI25BS3 -rw-r--r-- root root 38 2016-09-16 04:29 SOI25BS3_BU64747GWZ.dat -rw-r--r-- root root 481 2016-09-16 04:29 SOI25BS3_BU64747GWZ_XCF.dat -rw-r--r-- root root 3079 2016-09-16 04:29 SOI25BS3_BU64747GWZ_XFW.dat -rw-r--r-- root root 84672 2016-09-16 04:29 SOI25BS3_IMX300.dat drwxr-xr-x root shell 2016-09-16 04:29 SOI25BS4 -rw-r--r-- root root 38 2016-09-16 04:29 SOI25BS4_BU64747GWZ.dat -rw-r--r-- root root 481 2016-09-16 04:29 SOI25BS4_BU64747GWZ_XCF.dat -rw-r--r-- root root 3079 2016-09-16 04:29 SOI25BS4_BU64747GWZ_XFW.dat -rw-r--r-- root root 84672 2016-09-16 04:29 SOI25BS4_IMX300.dat -rw-r--r-- root root 15528 2016-09-16 04:29 default.dat -rw-r--r-- root root 1604 2016-09-16 04:29 flash.dat -rw-r--r-- root root 9328 2016-09-16 04:29 snapshot.dat -rw-r--r-- root root 11968 2016-09-16 04:29 streaming.dat -rw-r--r-- root root 17248 2016-09-16 04:29 supported.dat -rw-r--r-- root root 28 2016-09-16 04:29 version.dat

I can find some of the files in other ROMs, so says Google.

EDIT: Renamed the folder resulting in yet another boot loop. Of course, I should have created a blank one under this name. However, I am going to do a factory reset and will report back if and how things change, both for the folder and for the Xposed framework.

[eos4git]

OK, I have finally found the root cause. Well, perhaps just the source of those mysterious .so files. One of the steps for me to take on the way to a fully rooted device preserving Sony's DRM keys is this script: http://forum.xda-developers.com/xperia-z5/development/root-automatic-repack-stock-kernel-dm-t3301605

It can also do this:

If you want to integrate xposed as well just place the distribution for you device and Android version in the same directory. (e.g. xposed-v86-sdk23-arm64.zip). Only support with Android 6.0 (sdk 23) and higher.

Now, if you take a look at the most recent attached file rootkernel_v5.0_Windows_Linux.zip, you will find those .so modules inside. When I was installing the new ROM, I had this repack script also include v86 of the SDK23 framework. The first boot failed back then just as it does now. Afterwards, I figured out that reverting to v85 solves the boot loop. That I think now kind of explains why both v86 and v87 get started. I reckon, there is some flaw in the logic of the repack script and I am going to post a cross-reference to our discussion here on their forum.

Meanwhile, I have tried the full wipe to no avail. :-(

[eos4git]

Good morning! I have meanwhile cross-referenced the issue hoping to find someone on the other forum dedicated to the repack script who could tell us why that script works the way it does and most importantly how to resolve the issue in a non-invasive fashion:

http://forum.xda-developers.com/xperia-z5/development/root-automatic-repack-stock-kernel-dm-t3301605/page149#post69844577

The function I mention in my post there is this:

`add_xposed()
{
    local file
    local LIBDIR
    local install
    local pattern
    local XPOSED
    local XPOSED_DIR=xposed

    [ $PLATFORM -eq 64 ] && pattern=xposed-*sdk${SDK}-arm64.zip || pattern=xposed-*sdk${SDK}-arm.zip

    for file in $pattern; do XPOSED=$file; done
    [ ! -f $XPOSED ] && return

    if [ "${VERSION%%.*}" != "6" ]; then
        ui_print "  Skipping xposed integration. Only supported for Android 6"
        return
    fi

    ask "- Found $XPOSED. Install?" 1 install
    [ $install -ne 1 ] && return

    perform rm -rf $XPOSED_DIR
    perform mkdir -p $XPOSED_DIR
    unzip_with_timestamp $XPOSED $XPOSED_DIR

    add_vendor_overlay

    local policy=$(find_file $RAMDISK/sepolicy)
    add_policy $policy dex2oat  apk_tmp_file    dir      search
#   Avoid the LD_PRELOAD is removed on transition from installd to dex2oat
    add_policy $policy installd         dex2oat         process  noatsecure
    add_policy $policy untrusted_app    dex2oat         process  noatsecure

    perform mkdir -p $RAMDISK/$VENDOR_OVL/framework
    perform cp  $XPOSED_DIR/system/framework/XposedBridge.jar       $RAMDISK/$VENDOR_OVL/framework/XposedBridge.jar@0644
    perform cp  $XPOSED_DIR/system/xposed.prop                      $RAMDISK/$VENDOR_OVL/xposed.prop@0644
    add_with_xz $XPOSED_DIR/system/lib/libart.so                    $RAMDISK/$VENDOR_OVL/lib/libart.so
    add_with_xz $XPOSED_DIR/system/lib/libart-compiler.so           $RAMDISK/$VENDOR_OVL/lib/libart-compiler.so
    perform cp  $XPOSED_DIR/system/lib/libsigchain.so               $RAMDISK/$VENDOR_OVL/lib/libsigchain.so@0644
    perform cp  $XPOSED_DIR/system/lib/libxposed_art.so             $RAMDISK/$VENDOR_OVL/lib/libxposed_art.so@0644
    perform cp  $TOOLS/libxposed_preload32.so                       $RAMDISK/$VENDOR_OVL/lib/libxposed_preload.so@0644
    perform cp  $TOOLS/libxposed32.so                               $RAMDISK/$VENDOR_OVL/lib/libxposed.so@0644
    perform cp  $TOOLS/libxposed_safemap32.so                       $RAMDISK/$VENDOR_OVL/lib/libxposed_safemap.so@0644

    if [ $PLATFORM -ne 64 ]; then
        perform cp  $XPOSED_DIR/system/lib/libart-disassembler.so       $RAMDISK/$VENDOR_OVL/lib/libart-disassembler.so@0644
    else
        perform cp  $XPOSED_DIR/system/lib64/libart-disassembler.so     $RAMDISK/$VENDOR_OVL/lib64/libart-disassembler.so@0644
        add_with_xz $XPOSED_DIR/system/lib64/libart.so                  $RAMDISK/$VENDOR_OVL/lib64/libart.so
        perform cp  $XPOSED_DIR/system/lib64/libsigchain.so             $RAMDISK/$VENDOR_OVL/lib64/libsigchain.so@0644
        perform cp  $XPOSED_DIR/system/lib64/libxposed_art.so           $RAMDISK/$VENDOR_OVL/lib64/libxposed_art.so@0644
        perform cp  $TOOLS/libxposed_preload64.so                       $RAMDISK/$VENDOR_OVL/lib64/libxposed_preload.so@0644
        perform cp  $TOOLS/libxposed64.so                               $RAMDISK/$VENDOR_OVL/lib64/libxposed.so@0644
        perform cp  $TOOLS/libxposed_safemap64.so                       $RAMDISK/$VENDOR_OVL/lib64/libxposed_safemap.so@0644
    fi
    add_preload libxposed_preload.so

    perform rm -rf $XPOSED_DIR
}`

[rovo89]

Looks to me like an attempt to achieve systemless Xposed... But as you said, it seems to be a rather invasive way that obviously causes boot loops.

[eos4git]

OK, I have finally managed to solve this. Because the kernel repack script really does make Xposed system-less, you cannot simply go ahead and use the regular Xposed installer to upgrade the framework to the next version. The reason for this is that the whole point of what I think is also called overlay is not to touch the system partition at all. Instead, things like SuperSU or Xposed can go into the kernel boot image. This way the system partition can be kept read-only at all times to increase the overall level of security against malicious apps for instance. Anyway, upgrading Xposed would then also need to be done by incorporating the new framework version into said kernel image instead of using the regular installer. There is another way of doing so:

http://forum.xda-developers.com/xposed/unofficial-systemless-xposed-t3388268

Lastly, I want to be able to make changes to /system (e.g. hosts file). Thus, I had to simply use the same repack script, but without placing the framework ZIP into its folder this time to avoid making it system-less again. Flashing the new kernel image completely resolved the issue for me.

rovo89, thank you so much for all the hard work and for you support throughout this issue. Much appreciated.