The first third-party recovery package that we are going to look at is the famous Xposed recovery package. To install Xposed on our devices, we can install it after we root our device or we can apply an update package using recovery.
The Xposed update packages can be downloaded from the following URL:
http://dl-xda.xposed.info/framework/
The version that we will use in this section is version 87 (xposed-v87-sdk23-x86.zip).
Since the update package is a ZIP file, we can extract it to a temporary space and look at the internal details inside the update package:
$ ls -1F META-INF/com/google/android/
flash-script.sh
genymotion-ready
update-binary
updater-script
$ cat META-INF/com/google/android/updater-script
# this is a dummy file, the magic is in update-binary and flash-script.sh
As we can see, the updater-script is just a dummy file; updater-binary actually executes the flash-script.sh script, which is a shell script.
If we power on our x86vbox device and enter recovery to apply this package, we will get the following error message in /tmp/recovery.log:
...
******************************
Xposed framework installer zip
******************************
- Mounting /system and /vendor read-write
I:1 key(s) loaded from /res/keys
Verifying update package...
I:comment is 1738 bytes; signature 1720 bytes from end
I:whole-file signature verified against RSA key 0
I:verify_file returned 0
Installing update...
******************************
Xposed framework installer zip
******************************
- Mounting /system and /vendor read-write
mount: can't find /system in /proc/mounts
! Failed: /system could not be mounted!
E:Error in /sideload/package.zip
(Status 1)
Installation aborted.
We can see from the error message that the flash-script.sh script cannot mount the /system partition.
To find out the issue, we can look at the following code snippet of this script and compare it to the preceding error message:
...
echo "******************************"
echo "Xposed framework installer zip"
echo "******************************"
if [ ! -f "system/xposed.prop" ]; then
echo "! Failed: Extracted file system/xposed.prop not found!"
exit 1
fi
echo "- Mounting /system and /vendor read-write"
mount /system >/dev/null 2>&1
mount /vendor >/dev/null 2>&1
mount -o remount,rw /system
mount -o remount,rw /vendor >/dev/null 2>&1
if [ ! -f '/system/build.prop' ]; then
echo "! Failed: /system could not be mounted!"
exit 1
fi
...
As we can see, the reason it fails is because this script assumes the mount command is available when it executes. In our environment, we do have the mount command available, but it is not in the execution path by default. The mount command in our environment is a symbolic link of busybox. This version of mount needs the standard Linux mount table, /etc/fstab, instead of /etc/recovery.fstab.
With the preceding analysis, we can just simply update our start script to fix the issues as follows:
On early init:
# for /bin/busybox
symlink /bin/ld-linux.so.2 /lib/ld-linux.so.2
symlink /bin/busybox /bin/sh
symlink /bin/busybox /sbin/sh
symlink /etc/recovery.fstab /etc/fstab
On init:
export PATH /bin:/sbin:/system/bin
mkdir /vendor
exec -- /bin/sh /sbin/init.x86vbox.sh
...
In the init.recovery.x86vbox.rc script, we add the /bin path for busybox to the PATH environment variable. We create a /etc/fstab symbol link to /etc/recovery.fstab. With these changes, we build recovery and apply the Xposed package again. We can see from the following screenshot that the package is applied successfully:
