Hi!
I want to create a script that runs during boot without the need of SManager.
I want to run this command at boot:
Code:
mount -o bind /storage/sdcard1/data/com.google.android.music/ /storage/sdcard0/Android/data/com.google.android.music/
That's what I think I should do:
I put this code in a file called "99userinit" and then push it via adb to "/system/etc/init.d" and then set the permissions of "99userinit" to 755. That's it.
1) Will this script work as expected in CyanogenMod 10.1?
2) Will it survive when I update my nightly?
I am currently running stock 10.1-20130603-NIGHTLY-i9100. No mods whatsoever.
Thank you!
My progress report
So I just tried to do it by myself, here's what happened:
This is what my "99userinit" script looks like:
Code:
#!/system/bin/sh
mount -o bind /storage/sdcard1/data/com.google.android.music/ /storage/sdcard0/Android/data/com.google.android.music/
Did not work as planned, so I went to the teamhacksung irc channel and got some help.
I put it in "/system/etc/init.d/" and restarted the phone. Here's what I got:
Code:
127|[email protected]:/proc $ /system/xbin/run-parts -l /system/etc/init.d
/system/xbin/run-parts -l /system/etc/init.d
/system/etc/init.d/00banner
/system/etc/init.d/90userinit
/system/etc/init.d/99userinit
I/run-parts( 1871): mount: No such file or directory
I/run-parts( 1871): run-parts: /system/etc/init.d/99userinit exited with code 255
I/logwrapper( 1871): /system/xbin/run-parts terminated by exit(1)
Then I put my script to /data/local/userinit.d/" and restarted the phone. Here's what I got:
Code:
[email protected]:/ # /system/xbin/run-parts -l /data/local/userinit.d
/system/xbin/run-parts -l /data/local/userinit.d
/data/local/userinit.d/99userinit
I/busybox ( 1941): mount: No such file or directory
I/busybox ( 1941): run-parts: /data/local/userinit.d/99userinit exited with code 255
I/logwrapper( 1941): busybox terminated by exit(1)
I will update this thread, as I progress further.
Problem solved!
The script now works fine, here's what it looks like:
Code:
#!/system/bin/sh
sleep 50s
mount -o bind /storage/sdcard1/data/com.google.android.music/ /storage/sdcard0/Android/data/com.google.android.music/
Why wait 50 seconds you ask? Because 40 seconds are too short. :-/
Because I am not very satisfied with the sleep command, I will look a bit further into shell scripting and the "ACTION_MEDIA_SCANNER_FINISHED". But seeing this as my first programming project ever, it's going to take me a while
Hi,
Can't really find a tutorial for our phone, so I'll be, well, making a tutorial
Some notes:
- Compiling is really slow, VERY. Probably RasPi speed.
- Putting the chroot in a specific location helps, due to our phone having weird mountpoints (try typing `mount` and see what happens)
- You can ADB shell into the phone, type "stop" so Zygote is stopped (less RAM usage, less CPU usage, basically pure Linux is running)
- ^ Remember to type "start" after finished playing with the chroot, or you get a frozen phone until forced reboot!
You may be able to adapt this guide to other distros too (although unlikely)
REQUIREMENTS
- Enough juice for playing games for a long time
- A WORKING busybox with "tar xvjpf" available
- You are rooted
1. First of all, su and mount root read/write.
Code:
su; mount -o remount,rw /
2. cd into /data/local
Code:
cd /data/local
3. mkdir linux (or other names if you prefer)
Code:
mkdir linux
4. cd into it
Code:
cd linux
5. Download a stage3 tarball USE ARMv7l, our phone isn't hard-floated and put it in current directory.
- If you use an external browser, make sure the permissions isn't set to r--------, chmod 755 to be sure
- If you use wget, you probably don't have to worry about permissions
6. Extract it. Replace blahblahblah with your file name
Code:
tar xvjpf blahblahblah.tar.bz2
7. Make a chroot script which contains all the necessary bind mounts and commands. Make sure it is in the same dir as your chroot!
Code:
#!/system/bin/sh
# Enable network forwarding to the chroot
sysctl -w net.ipv4.ip_forward=1
# Mount proc to "current directory"/proc
mount -t proc proc proc/
# Mount sys, bind
mount -o bind /sys sys/
# Mount dev, bind
mount -o bind /dev dev/
# Symlink proc/self/fd to dev/fd, or portage will fail
ln -s proc/self/fd dev/
# Write resolvconf
echo "8.8.8.8" > etc/resolv.conf
# Make sure the permissions are correct
chmod 755 etc/resolv.conf
# Chroot using /bin/bash as shell
chroot . /bin/bash
Then chmod 755 the script
Code:
chmod 755 chroot.sh
8. All Gentoo users should know this...
Code:
source /etc/profile
9. Edit /etc/portage/make.conf
Code:
nano /etc/portage/make.conf
10. Add these lines to it
Code:
# This will disable userfetch, making name resolution work.
FEATURES="-userfetch"
11. Adjust USE flags and other configs as necessary... save it
12. Enjoy Gentoo on your phone! :laugh::laugh:
13. Just Ctrl+D to exit chroot
Hi, I've recently acquired a Trekstor Surftab breeze 10.1 quad and my first (admittedly inexperienced) attempts at rooting it have failed miserably.
The tablet is a 10.1 inch 8GB device with a Mediatek MT8127 running Android 4.4.2 (Kernel 3.4.67 [email protected] #1). I tried first with Towelroot (including the various advanced modes), which did nothing, not even the temporary root option. Kingo Root and iRoot (former vRoot) are able to connect to the tablet in debug mode, but after trying several scripts and rebooting the device a few times they ultimately failed.
I'd rather not change the recovery without a having a backup, but I tried MTK Tools to at least get some useful information. I couldn't get a scatter file because the button was greyed out (I don't think the program is fully compatible with the MT8127), but the partitioning info was slightly different from other MT8127-based devices (I checked the Cube U27GT MT8127 tablet). Getting a scatter file from an existing ROM (or just modifying a ROM to add the su binary) seems to be out of the question, because I couldn't find one on the Trekstor site and a quick Google search gave me nothing. I also tried to get temporary root but it failed with a suggestion to install CWM recovery.
Also, just in case I was being an idiot and the tablet came with the su binary already installed (other Trekstor devices do), I tried installing SuperSU directly, but I had no such luck.
If I find anything else I'll post it here, but for the time being I've run out of ideas. Any suggestions?
I've finally cracked it and been able to put together some notes. They are intended for the Surftab Quad 10.1, but they might be useful with some modifications for other devices based on a Mediatek SOC that can't be rooted using the usual tools (or if you don't trust the usual tools). I've tried to attach the programs I've used, but I've been having a lot of trouble because some files are too large. You can get everything from these Mega links instead:
ext4_utils_new_cygwin_fixed.tar.gz: https://mega.co.nz/#!YIkhFTRJ!uemCzV5fTlXoyK61Vr3Ib-sPXYlzmrffYG7YwUxXaU0
MT6577 USB VCOM drivers.rar: https://mega.co.nz/#!dcNx2QBC!eHyKtnwbVc2Gj5hCUQXQIlQsv9G3dGXWvPEvrB15mNw
MT8127_Android_scatter_surftab_quad_101.txt: https://mega.co.nz/#!Yd0nnRoL!s5ztQIwwZLa3i89zVU9vFJL0xZXg5LKqIDSkRAdj45k
MtkDroidTools v2.5.3.zip: https://mega.co.nz/#!0FVxjILC!0-FOlPfT_OIRETYj_MsJofmse7zBeRMsSumJLicj5sM
spflash_5.14.16.zip: https://mega.co.nz/#!hcE0HKBJ!mkcdVjXBOUs7W1GhTF_qssgO14GNGs7kSWaOE9FJx2o
UPDATE-SuperSU-v2.45.zip: https://mega.co.nz/#!BUMzRaaR!R7_kGU7UN3SchcaEDCxKW7Oehfoi0PDsD-OeX9gJh0M
1) Make (or in this case check) the scatter file with MTK Droid Tools.
a) Turn on the device.
b) Enable USB debug.
c) Connect it to the PC.
d) Open MTK Droid Tools.
e) Check that the device information is correct, view block map, compare with scatter file and modify if needed.Alternatively, you can use the ADB terminal (it can be opened from MTK Droid Tools) and use the command “adb pull /proc/dumchar_info”. The resulting text file should contain the same information.
2) Install the VCOM drivers (I provide the Win7 version)
http://forum.xda-developers.com/showthread.php?t=2206421
http://forum.xda-developers.com/general/rooting-roms/guide-mediatek-spflashtool-failure-t2936933
The gist of it is, use USBDeview to remove any old VCOM drivers, install, reboot and plug in the switched off tablet. A new COM port-type device should flash for an instant in the device admin. Some guides recommend to change the preloader driver for DA, but in this case I found it not to be necessary. That said, the connection is a bit finicky and the USB cable that comes with the device and the port in the device itself seem to be pretty crappy, so in later steps it gave repeated COM errors unless I kept pressing on the micro USB connector or used a different cable altogether (the one belonging to my Kindle, to be precise). After a bit of trial and error, I also had a bit of trouble if the COM port assigned to the device was above port 9. That can be set in the device properties dialog, under the “Port configuration” tab and in “Advanced options”.
USBDeview might be necessary.
http://www.nirsoft.net/utils/usb_devices_view.html
3) Extract the system image (and make a full backup, just in case) with SP Flash Tools.
a) With the device unplugged and turned off, start SP Flash Tool.
b) Load the scatter file.
c) Under the Readback tab, click on “Add” and double click on the new field. I recommend to back up the entire device first, so name the file “full_dump.img” or somesuch and save from 0x00000000 to 0x4db00000, which would be everything but the user data and BMTPOOL. Then we add a second dump, named “system.img” starting on 0x5d00000 and with size 0x40000000. Those values come from the scatter file. They shouldn’t change if the device is the same, but if they do modify them as fit.
c) With the device turned off, plug the micro-usb side of the cable first (it’s more convenient that way), click “read back” and insert the cable into the pc. As mentioned before, the process can fail for many reasons. Sometimes unplugging the device, pressing briefly the tablet’s reset button and trying again helps.
4) Now prepare to continue working on Linux, a virtual machine like VirtualBox running Ubuntu should be enough. A bit over 2GB of free space will be needed.
a) Create a work directory, copy the system.img, ext4 utils and SuperSU files into it and open a terminal there.
b) If they aren't installed already, install compression and compilation tools (I might have been left out a few packages, I didn't have a clean setup to test it; if something isn't installed by default, finding the package shouldn't be hard). Assuming you are using Ubuntu:
Code:
sudo apt-get install unzip build-essential
c) Extract everything and compile the ext4 utils.
Code:
tar -xf ext4_utils_new_cygwin_fixed.tar.gz
unzip -d supersu UPDATE-SuperSU-v2.45.zip
cd ext4_utils_new; make; cd ..
d) Mount the original system image and copy everything it contains to a new directory.
Code:
mkdir system_old system_root
sudo mount -t ext4 -o loop system.img ./system_old
sudo cp -a system_old/* system_root
4) Install the SuperSU binaries and app.
The package I've included is intended to be installed automatically by the recovery menu, but we are going to do it manually by following the steps described in the setup script (supersu/META-INF/com/google/android/update-binary):
Code:
# API source target chmod chcon required
#
# 7-19 common/Superuser.apk /system/app/Superuser.apk 0644 u:object_r:system_file:s0 gui
# 20+ common/Superuser.apk /system/app/SuperSU/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 17+ common/install-recovery.sh /system/etc/install-recovery.sh 0755 *1 required
# 17+ /system/bin/install-recovery.sh (symlink to /system/etc/...) required
# *1: same as /system/bin/toolbox: u:object_r:system_file:s0 if API < 20, u:object_r:toolbox_exec:s0 if API >= 20
#
# 7+ ARCH/su /system/xbin/su *2 u:object_r:system_file:s0 required
# 7+ /system/bin/.ext/.su *2 u:object_r:system_file:s0 gui
# 17+ /system/xbin/daemonsu 0755 u:object_r:system_file:s0 required
# 17+ /system/xbin/sugote 0755 u:object_r:zygote_exec:s0 required
# *2: 06755 if API < 18, 0755 if API >= 18
#
# 19+ ARCH/supolicy /system/xbin/supolicy 0755 u:object_r:system_file:s0 required
# 19+ ARCH/libsupol.so /system/lib(64)/libsupol.so 0644 u:object_r:system_file:s0 required
#
# 17+ /system/bin/sh or mksh *3 /system/xbin/sugote-mksh 0755 u:object_r:system_file:s0 required
# *3: which one (or both) are available depends on API
#
# 21+ /system/bin/app_process32 *4 /system/bin/app_process32_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_process64 *4 /system/bin/app_process64_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_processXX *4 /system/bin/app_process_init 0755 u:object_r:system_file:s0 required
# 21+ /system/bin/app_process (symlink to /system/xbin/daemonsu) required
# 21+ *4 /system/bin/app_process32 (symlink to /system/xbin/daemonsu) required
# 21+ *4 /system/bin/app_process64 (symlink to /system/xbin/daemonsu) required
# *4: Only do this for the relevant bits. On a 64 bits system, leave the 32 bits files alone, or dynamic linker errors
# will prevent the system from fully working in subtle ways. The bits of the su binary must also match!
#
# 17+ common/99SuperSUDaemon *5 /system/etc/init.d/99SuperSUDaemon 0755 u:object_r:system_file:s0 optional
# *5: only place this file if /system/etc/init.d is present
#
# 17+ 'echo 1 >' or 'touch' *6 /system/etc/.installed_su_daemon 0644 u:object_r:system_file:s0 optional
# *6: the file just needs to exist or some recoveries will nag you. Even with it there, it may still happen.
#
# It may seem some files are installed multiple times needlessly, but
# it only seems that way. Installing files differently or symlinking
# instead of copying (unless specified) will lead to issues eventually.
#
# The following su binary versions are included in the full package. Each
# should be installed only if the system has the same or newer API level
# as listed. The script may fall back to a different binary on older API
# levels. supolicy are all ndk/pie/19+ for 32 bit, ndk/pie/20+ for 64 bit.
#
# binary ARCH/path build type API
#
# arm-v5te arm aosp static 7+
# x86 x86 aosp static 7+
#
# arm-v7a armv7 ndk pie 17+
# mips mips ndk pie 17+
#
# arm64-v8a arm64 ndk pie 20+
# mips64 mips64 ndk pie 20+
# x86_64 x64 ndk pie 20+
#
# Note that if SELinux is set to enforcing, the daemonsu binary expects
# to be run at startup (usually from install-recovery.sh, 99SuperSUDaemon,
# or app_process) from u:r:init:s0 or u:r:kernel:s0 contexts. Depending
# on the current policies, it can also deal with u:r:init_shell:s0 and
# u:r:toolbox:s0 contexts. Any other context will lead to issues eventually.
#
# After installation, run '/system/xbin/su --install', which may need to
# perform some additional installation steps. Ideally, at one point,
# a lot of this script will be moved there.
#
# The included chattr(.pie) binaries are used to remove ext2's immutable
# flag on some files. This flag is no longer set by SuperSU's OTA
# survival since API level 18, so there is no need for the 64 bit versions.
# Note that chattr does not need to be installed to the system, it's just
# used by this script, and not supported by the busybox used in older
# recoveries.
#
# Non-static binaries are supported to be PIE (Position Independent
# Executable) from API level 16, and required from API level 20 (which will
# refuse to execute non-static non-PIE).
#
# The script performs serveral actions in various ways, sometimes
# multiple times, due to different recoveries and firmwares behaving
# differently, and it thus being required for the correct result.
What the script is supposed to do depends on the API version, which can be identified by doing:
Code:
cat system_root/build.prop | grep "ro.build.version.sdk="
We should have API version 19, but at one point the instructions are misleading. When adjusting the security context of install-recovery.sh it states that it should match that of toolbox, which is correct, but next gives values for different API versions which do not match our case. We shouldn't trust them and use
Code:
ls -Z system_root/bin/toolbox
to obtain the right value, in our case ubject_r:toolbox_exec:s0 (as in API version higher than 20).
Next I give all the commands, so assuming the directory names are the same I used they can just be copied and pasted into the terminal:
Code:
sudo cp supersu/common/Superuser.apk system_root/app/
sudo chmod 0664 system_root/app/Superuser.apk
sudo chcon u:object_r:system_file:s0 system_root/app/SuperSU/SuperSU.apk
sudo cp supersu/common/install-recovery.sh system_root/etc/
sudo chmod 0755 system_root/etc/install-recovery.sh
#we have to copy the chcon of system_root/bin/toolbox: ls -Z system_root/bin/toolbox, the original script is misleading or our android setup isn't standard.
sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
sudo ln -s /system/etc/install-recovery.sh system_root/bin/install-recovery.sh
sudo cp supersu/armv7/su system_root/xbin/
sudo mkdir system_root/bin/.ext
sudo cp supersu/armv7/su system_root/bin/.ext/.su
sudo chmod 0755 system_root/xbin/su system_root/bin/.ext/.su
sudo chcon u:object_r:system_file:s0 system_root/xbin/su system_root/bin/.ext/.su
sudo cp supersu/armv7/su system_root/xbin/daemonsu
sudo cp supersu/armv7/su system_root/xbin/sugote
sudo chmod 0755 system_root/xbin/daemonsu system_root/xbin/sugote
sudo chcon u:object_r:system_file:s0 system_root/xbin/daemonsu
sudo chcon u:object_r:zygote_exec:s0 system_root/xbin/sugote
sudo cp supersu/armv7/supolicy system_root/xbin/
sudo cp supersu/armv7/libsupol.so system_root/lib/
sudo chmod 755 system_root/xbin/supolicy
sudo chmod 0755 system_root/xbin/supolicy
sudo chmod 0644 system_root/lib/libsupol.so
sudo chcon u:object_r:system_file:s0 system_root/xbin/supolicy
sudo chcon u:object_r:system_file:s0 system_root/lib/libsupol.so
sudo cp system_root/bin/mksh system_root/xbin/sugote-mksh
sudo chmod 0755 system_root/xbin/sugote-mksh
sudo chcon u:object_r:system_file:s0 system_root/xbin/sugote-mksh
6) Generate a new image file with make_ext4fs.
Code:
./ext4_utils_new/make_ext4fs -a system -l 1G system_root.img system_root/
We can now mount it and verify that the files are in place and with the right permissions.
Code:
mkdir system_test
sudo mount -t ext4 -o loop system_root.img ./system_test
ls -la system_test/app/SuperSU.apk
ls -Z system_test/app/SuperSU.apk
ls -la system_test/xbin/su
ls -Z system_test/xbin/su
And finally unmount everything
Code:
sudo umount system_root
sudo umount system_test
7) Return to Windows and flash our rooted system image.
a) Open the flash tool, checking that we have loaded the right scatter file.
b) Select “download only” in the drop-down menu, make sure only “ANDROID” is checked in the list and, double-clicking that entry, pick the system_rooted.img file we have just created.
c) Just as when we extracted the image, we press “Download” and plug in the USB cable with the device turned off. Note: If you have been using a virtual machine, at some point mounted the rooted image to check that all the files were in place and forgot to unmount it, the file will be locked and the flash tool can spit out an error message. It took me a few tries to notice and shut down the VM completely. Don’t be me.
8) After it has finished flashing, unplug the device and boot it again. The first time it boots it should show a boot message saying that it’s updating one app, and once it’s finished we should have a working rooted tablet.
Same here with the trekstor surftab breeze 7.0 quad (ST70408-2).
I have tried everything with no results...
did you try rootgenius? (shuame.com/en/root/)
Y es. I have tried with no results.
Sent from my XT1032 using xda premium
I did it the hard way, eventually. I dumped the original rom, mounted it on linux, copied all the SU binaries manually in the right places (following the instructions in the installation script), and flashed it back.
I'm not sure if I can get in trouble for uploading the whole rooted ROM, but as soon as I have some free time I'd like to at least post more detailed instructions, the programs I used and the scatter file for my 10.1 quad in case someone finds it useful.
I would really appreciate if you could find the time to add a description.
I have a Surftab Breeze 7.0 quad and I am struggeling with backing it up and rooting it.
Looking forward to reading your notes.
sdfsdfgdhshxzv said:
I did it the hard way, eventually. I dumped the original rom, mounted it on linux, copied all the SU binaries manually in the right places (following the instructions in the installation script), and flashed it back.
I'm not sure if I can get in trouble for uploading the whole rooted ROM, but as soon as I have some free time I'd like to at least post more detailed instructions, the programs I used and the scatter file for my 10.1 quad in case someone finds it useful.
Click to expand...
Click to collapse
can u attach your scatterfile plz?
mr9to5 said:
can u attach your scatterfile plz?
Click to expand...
Click to collapse
Sure. This is for my MT8127-based Trekstor Surftab Quad 10.1.
Sorry about the rest of my notes, I've just changed jobs and I'm having a few horribly busy weeks so I've had no time to make them presentable. But once you have the utilities to mount the image on linux, it's just a matter of extracting the supersu archive and looking into the setup script to see where every file goes, where to create links and which permissions to set for the right Android version.
I've finally added my step by step notes to the first post. I hope someone finds them useful.
sdfsdfgdhshxzv said:
I've finally added my step by step notes to the first post. I hope someone finds them useful.
Click to expand...
Click to collapse
very useful, but i have a big problem.
Code:
$ sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
chcon: ungültiger Kontext: u:object_r:toolbox_exec:s0: Datei oder Verzeichnis nicht gefunden
can u help?
mr9to5 said:
very useful, but i have a big problem.
Code:
$ sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
chcon: ungültiger Kontext: u:object_r:toolbox_exec:s0: Datei oder Verzeichnis nicht gefunden
can u help?
Click to expand...
Click to collapse
Hum... not sure what happened there. Can you please try this? (assuming you have used the same directory names I did, change them if you haven't)
Code:
ls -Z system_root/etc/install-recovery.sh
ls -Z system_old/bin/toolbox
sdfsdfgdhshxzv said:
Hum... not sure what happened there. Can you please try this? (assuming you have used the same directory names I did, change them if you haven't)
Code:
ls -Z system_root/etc/install-recovery.sh
ls -Z system_old/bin/toolbox
Click to expand...
Click to collapse
it works, but this errormessages are from selinux, the copied files have no content so we can´t change this.
Sucefull startet CWM recovery
not perfect but runs, incl adb root shell in recovery mode.
la solución al root de esta tablet esta aquí w w w . m g y u n . c o m /
100% efectiva.
---------- Post added at 12:47 PM ---------- Previous post was at 12:11 PM ----------
¿algun propietario de la surftab brisa 10.1 quad, me podría enviar las apk de bluetooth ?
es que manipulando un explorador root he borrado por equivocación estos archivos y no me funciona el bluetooth de la tablet.
gracias.
Hi everyone, I searched around but couldn't find anything similar.
On KitKat, I regularly insert my own messages into kernel and logcat logs from adb shell, either typing manually or with a batch file, in the following fashion:
Code:
adb shell "echo 'whatever' >/dev/kmsg"
adb shell "echo '\06title\0whatever\0' > /dev/log/main"
However on Lollipop, system logs (logcat) no longer use /dev/log/ but rather with a new "logd" mechanism with socket connection to /dev/socket/logdw for writing. However, if I simply modify my command to
Code:
adb shell "echo '\06title\0whatever\0' > [B]/dev/socket/logdw[/B]"
it does not work, instead giving an error message:
Code:
/system/bin/sh: can't create /dev/socket/logdw: No such device or address
But it does exist:
Code:
adb shell ls -l /dev/socket/logd*
srw-rw-rw- logd logd 1969-12-31 17:40 logd
srw-rw-rw- logd logd 1969-12-31 17:40 logdr
s-w--w--w- logd logd 1969-12-31 17:40 logdw
I'm not a software guy so not sure what is special with a socket connection. Is there any chance of being able to write to logcat directly with adb shell command, or will I need either an app or a compiled executable?
Thanks!
Came across this somewhat dated post as I was researching for the same thing.
I found a solution on stackoverflow dot com/a/33260551
Note, my phone is running 5.1.1, and you need to be rooted.
Code:
$ su -c which log && su -c log -h
/system/bin/log
USAGE: log [-p priorityChar] [-t tag] message
priorityChar should be one of:
v,d,i,w,e
Hi, I'm completly lost. I'm trying to get Daydream running on a Sony Xperia XZ Premium (XZP). I read that 2 files must be modified for this. I already edited the build.prop file in /system. But the second one, the handheld_core_hardware.xml is for some reason not where it should be. I backed up the TA-partion and flashed the firmware "G8141_MobilTel EAD BG_1309-2357_47.2.A.10.62_R2C" with the kernel "boot-G8141-47.2.A.10.62-hideunlock-magisk-19.3.img" following the instructions here on XDA. Using ADB I open a root shell (ADB shell, su) and try to copy a modified version of the XML file from data/local/tmp to system/etc/permissions after re-mounting /system in rw-mode. I got the file by extracting the ext4-image in the system.sin of the firmware pack and pushed it to tmp using ADB. When I try to copy the file, I either get "I/O error" or no error. In the latter case the file is nevertheless not copied and I get the I/O error when mounting to ro-mode again. It's also strange that in this case I can cat the contents and list it via ls -l but only if I use the exact name no wildcards. On next boot or when ro-mounting succeeds its completely gone.
This is how it looks on the shell:
Code:
127|G8141:/system/etc/permissions # ls -l handheld_core_hardware.xml
ls: handheld_core_hardware.xml: No such file or directory
1|G8141:/system/etc/permissions # cp /data/local/tmp/handheld_core_hardware.xml /system/etc/permissions
cp: /system/etc/permissions/handheld_core_hardware.xml: I/O error
1|G8141:/system/etc/permissions # ls -l /data/local/tmp
total 12
-rw-rw-rw- 1 shell shell 4877 2019-09-06 10:03 handheld_core_hardware.xml
drwxr-xr-x 2 root root 4096 2019-09-06 11:47 test
G8141:/system/etc/permissions # mount | grep system
/dev/block/dm-0 on /system type ext4 (rw,seclabel,relatime,block_validity,discard,delalloc,barrier,user_xattr)
/dev/block/sde33 on /system/vendor/firmware_mnt type vfat (ro,context=u:object_r:firmware_file:s0,relatime,gid=1000,fmas
k=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
/dev/block/sde37 on /system/vendor/bt_firmware type vfat (ro,context=u:object_r:bt_firmware_file:s0,relatime,uid=1002,gi
d=3002,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
/dev/block/sde34 on /system/vendor/dsp type ext4 (ro,seclabel,nosuid,nodev,relatime,data=ordered)
/sbin/.magisk/block/system on /sbin/.magisk/mirror/system type ext4 (ro,seclabel,relatime,block_validity,discard,delallo
c,barrier,user_xattr)
G8141:/system/etc/permissions #
What am I doing wrong?
Is there maybe a better way meanwhile to enable Daydream on unsupported devices?
I mean, it's a bad joke, Sony makes this great 4k display but doesn't support VR properly. Daydream even starts and is working just to block the view a second later with a big PopUp telling that the device is not compatible.