The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Adaptations/libhybris/FxtecPro1
From Mer Wiki
< Adaptations | libhybris(Difference between revisions)
m |
(→Development bugs:) |
||
| Line 24: | Line 24: | ||
- PEERSEC is not available which causes droid-hal-init to crash | - PEERSEC is not available which causes droid-hal-init to crash | ||
| + | |||
- CANNOT LINK EXECUTABLE … is not accessible for the namespace [https://github.com/mer-hybris/android_bionic/blob/droid-src-sony-aosp-8.1.0_r52_20190206/linker/linker.cpp#L1264 here] | - CANNOT LINK EXECUTABLE … is not accessible for the namespace [https://github.com/mer-hybris/android_bionic/blob/droid-src-sony-aosp-8.1.0_r52_20190206/linker/linker.cpp#L1264 here] | ||
Fixed by simply changing linked if | Fixed by simply changing linked if | ||
| + | |||
- test_egl_configs works. test_hwc2 doesn't: | - test_egl_configs works. test_hwc2 doesn't: | ||
Revision as of 19:02, 5 June 2019
Keep sfos on A slot.
Installing image
There is no TWRP available so it's csdmplicated. I tried to build image manually but it had corrupted ext4 (for whatever reason). You can install stock on B slot and install sfos from stock (not tested).
Instructions:
- put .tar.bz2 file onto SDCARD - using fastboot format userdata - fastboot format:ext4 userdata - fastboot set-active a (formatting userdata will change slot most likely) - flash kernel - it will boot to ramdisk then: - mkdir /sdcard - mount /dev/mmcblk0p1 /sdcard - cp /sdcard/sfos.tar.bz2 /data/sailfishos-rootfs.tar.bz2 - Do as this script does (literally copy paste lines) updater-unpack.sh - after unpacking reboot and it should be fine
Development bugs:
- PEERSEC is not available which causes droid-hal-init to crash
- CANNOT LINK EXECUTABLE … is not accessible for the namespace here Fixed by simply changing linked if
- test_egl_configs works. test_hwc2 doesn't:
==12102== Invalid read of size 1 ==12102== at 0x53EC858: __fsetlocking (in /usr/libexec/droid-hybris/system/lib/libc.so)
well, that's interesting, means we have unhooked file function somewhere
__fsetlocking usage came from external/selinux/libselinux/src/init.c (statically linked to libpdx_default_transport.so), which we will neutralize anyway
