Related
Here are the 2.3.2 .img's compiled from aosp source for crespo (Nexus S)
We don't have a pure 2.3 ROM compiled from aosp source yet, so I decided build one, and here are the .img's from my build.
These can be used to restore Nexus S back to aosp, or flash all images for a pure aosp experience.
HOWEVER: These are NOT the official Google factory images for Nexus S, only compiled from source.
Attached are: system.img boot.img recovery.img userdata.img
Installation:
Code:
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash recovery recovery.img
fastboot flash userdata userdata.img
All images being provided work 100%, as I have it installed on my nexus S currently and flashed via fastboot.
disclaimer: WARNING! I am in no way shape or form responsible for ANY DAMAGE you may do to your phone. I am simply providing the files, however you decide to flash on your own, not me.
These images also do not contain any proprietary apps such as the Google apps (Maps, Market, Gmail, etc)
Clear? ok then, proceed to download
system .img link: http://www.mediafire.com/file/k2jopya0o416m8j/system.img
others are attached below.
UPDATE: these .img's are for 2.3.2
Attached bcm4329.ko module to fix wifi for users who flashed my boot.img on a non-aosp ROM (push to /system/modules)
2.3.2 OTA package
Here is the 2.3.2 ota update package for those of you who don't like/wanna use fastboot for whatever reason.
Rename as update.zip, place on sdcard and flash as usual.
http://www.mediafire.com/file/fl1nxdpleitd392/2.3.2_full_crespo-ota-eng-signed.zip
WARNING! This ota update package is fully stock, has NO ROOT or Google proprietary applications, and will revert you to the stock recovery.
Google Applications archive can be found here: http://goo-inside.me/gapps/
Atached below are the files needed to manually root: SuperUser.apk, su, busybox.
Code:
adb push SuperUser.apk /system/app
adb push su /system/xbin
adb push busybox /system/xbin
chmod 6775 /system/xbin/su
chmod 6775 /system/xbin/busybox
adb shell reboot
If terminal doesn't let you remount in adb you may have to do it through the phone. Place all root files on sdcard:
Code:
mount -o rw,remount /dev/block/mmcblk0p2 /system
cp /sdcard/SuperUser.apk /system/app/
cp /sdcard/su /system/xbin/
cp /sdcard/busybox /system/xbin/
chmod 6775 /system/xbin/su
chmod 6775 /system/xbin/busybox
Reboot with a battery pull.
reserved again. You Never know
Thanks alot I've been looking for the stock recovery img
Sent from my Nexus S using Tapatalk
brian6685 said:
Thanks alot I've been looking for the stock recovery img
Sent from my Nexus S using Tapatalk
Click to expand...
Click to collapse
The recovery image from this post sadly still does not allow to flash the update from Google.
Getting signature verification error and yes i reverted back to the boot.img posted here as well.
EDIT: the boot.img here is also breaking wifi.
thanks for the effort though
clubtech said:
The recovery image from this post sadly still does not allow to flash the update from Google.
Getting signature verification error and yes i reverted back to the boot.img posted here as well.
EDIT: the boot.img here is also breaking wifi.
thanks for the effort though
Click to expand...
Click to collapse
Why wouldn't the ota work if you were using the stock recovery? That's weird
Sent from my Nexus S using Tapatalk
clubtech said:
The recovery image from this post sadly still does not allow to flash the update from Google.
Getting signature verification error and yes i reverted back to the boot.img posted here as well.
EDIT: the boot.img here is also breaking wifi.
thanks for the effort though
Click to expand...
Click to collapse
??? I flashed everything before posting and all was working perfect. I flashed all .img's though, maybe wifi broke for having a different system image and different wifi modules than aosp.. I just flashed paul's rom and reverted to stock recovery.img without a hitch with the one I posted.
brian6685 said:
Why wouldn't the ota work if you were using the stock recovery? That's weird
Sent from my Nexus S using Tapatalk
Click to expand...
Click to collapse
That's because it is not really stock recovery, it is a recovery built from source.
I guess it does not have google's signature.
Do you know of anywhere I can get the stock recovery? Or does fastboot oem lock bring back stock recovery?
Sent from my Nexus S using Tapatalk
jroid said:
??? I flashed everything before posting and all was working perfect. I flashed all .img's though, maybe wifi broke for having a different system image and different wifi modules than aosp.. I just flashed paul's rom and reverted to stock recovery.img without a hitch with the one I posted.
Click to expand...
Click to collapse
I can install your recovery, no problem. but i am not able to use the update.zip from Google with your stock recovery (signature verification failed).
I also tried with you stock recovery and boot.img - same issue.
When i booted the device with you stock recovery + boot.img but my original (stock) system.img - wifi could not start.
clubtech said:
When i booted the device with you stock recovery + boot.img but my original (stock) system.img - wifi could not start.
Click to expand...
Click to collapse
That's probably where the problem lies. I flashed all .img's including my system.img and wifi worked perfectly
Does this include gapps?
Anderdroid said:
Does this include gapps?
Click to expand...
Click to collapse
no, they're aosp images built from source.
clubtech said:
When i booted the device with you stock recovery + boot.img but my original (stock) system.img - wifi could not start.
Click to expand...
Click to collapse
Issue fixed. Please see the OP.
Hi jroid,
I tried to compile the 2.3.1 sources from AOSP today and ran into hundrets of warnings (no errors though so I might be OK). I did some coding for linux before but have no experience building Android from source. Can you provide the steps required to build?
As far as I can tell my environment is setup properly: I did a fresk Debian 64bit, JDK 6 and all the packages listed on sources.android.com - even if the information listed there is outdated. I installed Eclipse as well but didn't use it so far because I want to get the unchanged AOSP build correctly first.
To build I ran env_setup.sh, then lunch and picked crespo, then make... that's where I'm stuck right now.
I want to get the base build correctly before starting any changes. I'd love to get this setup in a way that allows me to test the build in the emulator first and then flash to the NS... Not sure if that's the best way or using fastboot boot instead of flash to see if it's working properly directly on the device (all new to me, sorry if these are dumb questions).
I searched the forum and the wiki but didn't find general or NS specific documentation for AOSP builds...
ToSa2 said:
Hi jroid,
I tried to compile the 2.3.1 sources from AOSP today and ran into hundrets of warnings (no errors though so I might be OK). I did some coding for linux before but have no experience building Android from source. Can you provide the steps required to build?
As far as I can tell my environment is setup properly: I did a fresk Debian 64bit, JDK 6 and all the packages listed on sources.android.com - even if the information listed there is outdated. I installed Eclipse as well but didn't use it so far because I want to get the unchanged AOSP build correctly first.
To build I ran env_setup.sh, then lunch and picked crespo, then make... that's where I'm stuck right now.
I want to get the base build correctly before starting any changes. I'd love to get this setup in a way that allows me to test the build in the emulator first and then flash to the NS... Not sure if that's the best way or using fastboot boot instead of flash to see if it's working properly directly on the device (all new to me, sorry if these are dumb questions).
I searched the forum and the wiki but didn't find general or NS specific documentation for AOSP builds...
Click to expand...
Click to collapse
I'm away from my laptop right now, but get adb installed first. Repo sync then cd to /crespo and run extract-files.sh
.Build env_setup.sh
Lunch full_crespo-userdebug
Make
Warnings should be fine, I got them too and it compiled perfectly. If you get errors, u will know. The compile with stop
Sent from my Nexus S
Thanks!
I did the extract-files.sh now which I missed before - running make over night so I'll see tomorrow if I get any errors...
Any advice how to test minimizing the risk (emulator / fastboot boot)?
ToSa2 said:
Thanks!
I did the extract-files.sh now which I missed before - running make over night so I'll see tomorrow if I get any errors...
Any advice how to test minimizing the risk (emulator / fastboot boot)?
Click to expand...
Click to collapse
yea you can use the fastboot boot command to test. I personally just flashed all the images through fastboot and it booted fine. aosp 2.3.1 (which I compiled) is in my experience FASTER and more smooth than the stock rom that shipped with the NS. Call audio quality is MUCH more rich robust than it is on the factory builds. have no idea why but it is
Since the Google apps aren't included, I'm guessing they all may be downloaded/installed from the Market... is that correct?
Thanks,
jankyboy said:
Since the Google apps aren't included, I'm guessing they all may be downloaded/installed from the Market... is that correct?
Thanks,
Click to expand...
Click to collapse
no, not all. Only some, but this doesn't even include the market so you couldn't even do that. I'm compiling from source again and probably release an AOSP rom in a day or 2, maybe even today..
Lots of tools in a script...**** TARs are NOT to be flashed with Heimdall****
ADB Manager - push- pull - install- delete- backups - dial - reboot-menu
APK Editor - decompile - compile - flash - extract-from-zipped-rom
JAR Editor - same as above
ROM Manager - extractor - deodexer - zipalign - root injection - builder
TAR Manager - extractor - mounter - custom packager - tar2md5
Lots more...
You must have these installed on your PC:
java sdk - zip - tar - dirname - basename
TOOLs I included, in the bin folder, for the script to function:
SamsungSDK adb
SamsungSDK zipalign
JesusFreak's baksmali/smali
7z (see changelog)
I also included Heimdall and 7z (with licenses). Mainly I want to implement them in the future. Although java can make zips without META and folders can be pointed to better than zip. I chose to use zip anyways for now. I used pushd/popd instead of cd. Except the one time I was already into a folder then popd back "home". Of course going through some loops made it easier to pop out. But it still pains me to resort to such things. I like it clean. I am trying to call all locations completely from top dir. I am looking at using 7z to do the work soon. Also I am working on kernel development and dd backup ideas (the backing up is the easy part...even dd piped to the pc). Have fun. Peace.
Code:
[CENTER][U][B]Changelog:
[/B][/U][LEFT][U][B]Latest:[/B][/U]
[/LEFT]
[/CENTER]
[B]1.4[/B] (4-13-11)
Optimized ROM Signing
Optimized ROM Zipalign
Optimized TAR to MD5
Fixed ADB Delete Multiple Files
Fixed ADB Remote Dial *see note
Trimmed another ~200 lines of code
[B]1.3[/B] (4-12-11)
removed cp baksmali to decompiled jar - extra comments during tests
Optimized-Locate APK/JAR
Optimized-Flash APK/JAR
Trimmed ~150 lines of code
[B]1.2[/B] (4-12-11)
Optimized - The Decompiling and Compiling of APKs/JARs
Optimized - The ZIP/TAR/MD5 Extraction Process
...added more bootclass listings for deodex support - gingerbread
...recompiled 7z from source to include all CPUs
...started to implement 7z in the code
Trimed ~70 lines of code
[B]1.1[/B] (4-10-11)
Fixed a couple of issues...zipalign to force and display progress correctly
Tar Extractor was deleting the folder after extraction ...doh
cleaned up some code and made more messes elsewhere :-)
Trimmed ~500 lines of code
.
Note:
For adb shell remount command: I included a remount script in bin/script folder. Change settings as needed (in the remount script). It is currently set for rfs (voodoo disabled) change to ext4 (voodoo enabled) if needed.
The easy way:
0) edit script to your flavor
1) make script executable if it isn't already "chmod +x /path/to/file/remount" from terminal or right click.. file properties...permissions...enable execute
2) reboot phone into recovery via "ADB","Reboot Menu"
3) Drop the remount script into system/bin via "ADB", "Copy Files to Device"
4) Reboot phone normally via "ADB","Reboot Menu"
5) Remote Dial.
Side Note:
Remount script remounts system folder. Usage commands of remount from terminal are "adb shell remount rw" and "adb shell remount ro"
The_Ravager said:
This Script will package a ROM for flashing with Odin/Heimdall.
Click to expand...
Click to collapse
Slight correction, Heimdall does not use tar files, trying to flash a tar with Heimdall will very likely soft-brick your device.
Benjamin Dobell said:
Slight correction, Heimdall does not use tar files, trying to flash a tar with Heimdall will very likely soft-brick your device.
Click to expand...
Click to collapse
This extracts tars. Heimdall can flash your factoryfs.rfs param.lfs zImage modem.bin, what-have-you, once you do. This
will allow you to mount said factoryfs.rfs ... rip its guts out ...throw some new ones in....umount flash with heimdall but, this will ALSO repackage your modified factoryfs.rfs into tar or tar.md5 with a new zImage or modem.bin or any of the other selections for use with your windoze users.
So again for use with either method. I'll put a disclaimer.
This takes all the command line work out for newbies trying to mount their factoryfs because I've done it all for them. Then when I add the other components, deodex it, throw it back together with your custom framework, apps...there you go. Custom ODIN image. On the fly.
The version I'm waiting to release has
APK/JAR decompiling/compiling/push/pull.......ROM.zip builder..deodexer...and more....
EDIT: New version up. Again:
****DO NOT flash TARs with Heimdall***
Have fun with the build tools in the new version.
Sent from my GT-I9000 using Tapatalk
do you plan to include all of those other functions directly into the script, or will your script rely on any other tools that others have released? ex. deodexing, zip align
Looks great-- haven't tested it yet, but I browsed through all of the methods, and saw that you have made it modular rather than one long messy script, so I anticipate more functions/features going into it quite well! Kudos!
wvidrine said:
do you plan to include all of those other functions directly into the script, or will your script rely on any other tools that others have released? ex. deodexing, zip align
Looks great-- haven't tested it yet, but I browsed through all of the methods, and saw that you have made it modular rather than one long messy script, so I anticipate more functions/features going into it quite well! Kudos!
Click to expand...
Click to collapse
I'll include front end functions for the android sdk's adb server and zipalign tools. Also baksmali and smali.
Updated OP
New Version in OP
All discussion should go the SuperSU BETA thread
Attached find modified boot.img for the Nexus firmwares released so far. Together with SuperSU v2.50+ these allow root with SELinux in Enforcing mode.
These are the stock boot images from Google, with the ramdisk modified as follows:
- patched sepolicy
- disabled dmverity (if applicable)
- disabled forceencrypt (if applicable)
Rooting procedure:
- flash/upgrade to Marshmellow
- flash modified boot.img
- flash/boot TWRP and sideload latest v2.50+
Acquiring root without modifying the boot images is still under investigation. Please note that the current method will not be officially supported. Future roots may require a clean system: we are at a very early stage of root for 6.0, methods used are subject to change.
For the modders, you can do the sepolicy modifications yourself as follows:
- root a reference device (4.4+ with SELinux enabled) with v2.50+
- extract the sepolicy file from the target boot image's ramdisk
- with the reference device connected to ADB:
Code:
adb push sepolicy /data/local/tmp/sepolicy
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out"
adb shell su -c "chmod 0644 /data/local/tmp/sepolicy_out"
adb pull /data/local/tmp/sepolicy_out sepolicy_out
- replace the sepolicy file in the boot image's ramdisk with the sepolicy_out file
- profit
(this trick should also work on the Samsung 5.1.1 kernels that people are having issues with lately)
Fugu requires v2.51+
EXPERIMENT: Root without modifying /system
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Idea
To have root on modern Android versions, we need our files to be executable and our daemon to be started on boot. We normally do this by making modifications to /system, tapping into binaries and scripts executed by init. If we're also modifying the boot image, then we should be able to do all this without modifying system at all. A benefit of this is that it makes OTAs easier - reflashing the boot image is less hassle than reflashing system.
As the binaries should still be updatable, and we don't know the space we have available in the boot image itself, we're mounting a (writable) ext4 image with /su as mount point from /data, and modifying PATH accordingly. Interestingly, for reasons yet unknown to me, if the image is mounted r/o by init, later remounting it r/w causes a bunch of issues. So we're keeping it r/w (for root) for now.
An overlayfs/unionfs solution would be even more ideal, transparently placing files in /system without modifying the actual partition, but I have not been able to find one that is (a) compatible with all Android architectures and (b) not kernel dependent and (c) not GPL - or even just one of those requirements, really. It's technically all possible, it just needs to be done.
Caveats
- Apps with hardcoded paths to su (seriously?) will bork
- Factory reset unroots
- Factory reset wipes pin
- ...
- Bugs... Bugs everywhere!
Instructions
You must absolutely re-flash your stock /system partition, or the separate root instances will interfere with eachother. The installer for this experiment will not clean up old root files.
- Flash stock /system (and /vendor and /oem, if present)
- Flash the attached boot image
- Flash the attached SuperSU ZIP in TWRP
Ramdisk modifications
- include (post above this one)
- init.rc (devs: please open file for reference)
--- on init
------ mkdir /su ...
--- on post-fs-data
------ copy image from cache to data (for rooting without access to /data in custom recovery)
------ mount image to /su
--- service daemonsu
- init.environ.rc
--- export PATH, prepended with /su/bin
- file_contexts
--- /su(/.*)? ubject_r:system_file:s0
NOTE
- Not all SuperSU options are supported yet in this mode
- I have not tested with encrypted devices
- /system should never be remounted r/w, I hope I didn't miss anything here
- Root with modifying /system is also still operational. I can't predict what the exploiters will need.
- I'm not sure where we're going with this. Future roots may require a clean system.
BETA-SuperSU-v2.56-20151030013730.zip
Changes
(The changelogs for the specific SuperSU versions can be found here: http://forum.xda-developers.com/showpost.php?p=23427824&postcount=3)
2016.01.21
- v2.67 ZIP
2016.01.03
- v2.66 ZIP
2015.12.26
- v2.65 ZIP
2015.12.20
- v2.64 ZIP
2015.12.11
- v2.62-3 ZIP:
--- (systemless) ZIP: Fix calling wrong script name for custom patcher script
--- (systemless) ZIP: Improve APK overwrite
--- (systemless) ZIP: Do not move backups from /cache to /data, just copy them
(there are no changes to SuperSU itself compared to v2.62, just minor script changes in the ZIP)
2015.12.10
- v2.62 ZIP
2015.12.07
- v2.61 ZIP
2015.12.05
- v2.60 ZIP with automated boot image patcher
2015.10.30 #2
- Added systemless root experiment for other Nexus than hammerhead
2015.10.30
- Added systemless root experiment for hammerhead
2015.10.28
- Added Angler kernel
- Added Razor mra58u kernel
2015.10.20
- Added Bullhead kernel
2015.10.08
- New image for Fugu, requires v2.51
2015.10.07
- New images, should fix the factory reset issues some users with encrypted data were seeing
EXPERIMENT: Root without modifying /system #2: Automation
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Continuing on the previous post, here is SuperSU v2.62 BETA, with automated boot image patching. It's been tested by myself on various Samsung's running anything from 4.3 to 5.1, and all of the recent Nexus devices on 6.0. Even on CM13. Other users have tested it with success on various other devices.
If you are coming from any SuperSU install in /system, you must re-flash the stock system (and vendor and oem, if present) partition contents prior to installing this.
If you are coming from a SuperSU 2.56 system-less install, you must re-flash the stock boot image prior to installing this.
If you are coming from a SuperSU 2.60 system-less install, or were not rooted at all, then you can just flash the ZIP without any special prior instructions.
If TWRP offers you to keep /system read-only, indeed keep it read-only.
If TWRP tells you SuperSU is not installed, and asks you to install it, do not do it, you will break things!
If on Android 6.0 or Samsung 5.1, the ZIP installer will install SuperSU in systemless mode and patch the boot image. The boot image patcher currently only supports gzip compressed ramdisks and the standard Android boot image format. Some devices do not use the standard format, and many custom kernels use a compression other than gzip. A backup is made (/data/stock_boot_<sha>.img.gz) of the original boot image before patching it.
Further implementation details (including an updated list of changes to the ramdisk) are explained in the installer script itself, as usual.
Notes on 2.62+
A poor man's overlay is used on /system/xbin. We are creating a copy of /system/xbin in /su/xbin_bind, adding a symlink to /su/bin/su there, then mounting the entire thing on top of the original /system/xbin. This is likely to fix some compatibility issues with some apps, without actually modifying /system. Removing /su/xbin_bind and rebooting will disable this feature, or "echo BINDSYSTEMXBIN=false>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash.
If you have one of those devices that refuse to remount system r/w in Android such as the Nexus 6P, but you do want to do this, "echo FSTABSYSTEMRW=true>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash will patch the boot image in such a way that remounting will work. This feature itself breaks OTA compatibility, regardless of if you end up writing to /system or not.
Both of these features are likely temporary.
Notes on 2.64+
There have been a lot of changes to the ZIP installer. Hopefully they won't break a lot of installs. If 2.64 works well, it is likely to be promoted to the "main beta" in place of 2.52, and the How-To SU document will be updated with the relevant information.
A major change in setup is that the ZIP installer will try to detect 6.0 firmwares that can be rooted without doing a systemless install. In other words, a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu").
This may catch (a) firmwares that allow sepolicy reloading from /data but have a locked bootloader and (b) custom firmwares setup to handle this. Regarding the latter, while it is not as clean as systemless, those running custom firmwares are more likely to want to modify /system anyway, it is less likely to mess with updates to those firmwares, and it prevents the necessity of reflashing the ZIP after each kernel switch. Of course, the kernel's SELinux policies must support this! See this thread for details for devs.
Notes on 2.65+
As 2.65 adds /su/xbin, I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Notes on 2.67+
I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Downloads
BETA-SuperSU-v2.60-20151205163135.zip
BETA-SuperSU-v2.61-20151207213702.zip
BETA-SuperSU-v2.62-20151210170034.zip
BETA-SuperSU-v2.62-2-20151211155442.zip
BETA-SuperSU-v2.62-3-20151211162651.zip
BETA-SuperSU-v2.64-20151220185127.zip
BETA-SuperSU-v2.65-20151226141550.zip
BETA-SuperSU-v2.66-20160103015024.zip
BETA-SuperSU-v2.67-20160121175247.zip
The latest WIP version has become the main BETA version.
For all intents and purposes, this thread is closed. It will be cleaned up and unstickied in good time.
NOTE: Unfortunately I've had to remove links from this post because I'm a new user. I'll add them back in once I have enough posts.
I've been trying to edit a file in boot.img from the CyanogenMod 12.1 (huashan) nightlies but I'm experiencing some issues finding the right tools/methods for the job.
Most scripts I've found expect an Android Magic number at the beginning of the file but this simply isn't there. It seems there is no header at all that matches the specification from bootimg.h (missing link) though I did discover the cmdline argument at the end of the file with a hex editor.
After searching and experimenting for hours I found a script here (missing link) which enabled me to extract the kernel and ramdisk images despite the missing header but now I don't know how to repack the files into a boot.img of the same structure.
I've tried the following but it results in a boot.img that is about 40% larger than the orginal (despite me only adding one line of code) and has an entirely different structure (with an Android Magic number, etc.).
Code:
mkbootimg --base 0x00200000 --pagesize 2048 --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
I found this resource (TWRP, missing link) which mentions that Xperia devices have special boot images (or something like that, I didn't understand all of it) - this might explain why the boot.img structure is so different - but I can't find any further documentation on this or instructions on how to deal with the format.
The Xperia devices have a recovery-in-boot arrangement. This means that the recovery is booted using the regular kernel / boot image in the device. Team Win has worked with the FreeXperia device maintainers to come up with a way to extract the ramdisk from the FOTAKernel partition and use the ramdisk from that partition instead of the recovery that is included in the boot image of your device. This means that if you install current CM nightlies and flash TWRP to the FOTAKernel partition, you will be able to use TWRP instead of the CWM or CM recovery that normally comes in a CM boot image. Other boot images including stock kernels can be repacked to include this extraction utility to allow you to use TWRP from the FOTAKernel partition. This setup allows you to choose what recovery you want to have installed and allows you to update your recovery more easily. Unfortunately this setup requires that the boot image that you have installed include the ramdisk extraction utility.
Click to expand...
Click to collapse
So now I'm at a loss at how to continue. I would much appreciate any pointers, ideas or help in general.
@infernalpostcard , hopefully this tool made by @Adrian DC will help you out.
https://github.com/AdrianDC/android_huashan_bootimg_editor
Raienryu said:
@infernalpostcard , hopefully this tool made by @Adrian DC will help you out.
https://github.com/AdrianDC/android_huashan_bootimg_editor
Click to expand...
Click to collapse
Thanks. This looks really promising. I'm trying it out now...
EDIT: It worked! This is exactly what I needed. Unfortunately what I was actually trying to achieve (apply a fix to break a boot-loop my phone gets in, due to an encrypted filesystem) didn't work so I'll have to come up with new ideas.
You can flash this boot.img with fastboot on the latest stock ROM (S244) with an unlocked bootloader (no custom recovery needed).
The included Magisk is v13.6 (beta) and the Manager is v5.2.0.
From what I gather the modules won't install (or using something like Flashify won't work) because there are still f2fs bugs present (not only on this device, most android kernels have them). But I didn't fully test this so YMMV.
I did it this way because I only need root for some apps (like: Amaze, Termux, Wirebug, WiFiKeyShare, KISS launcher, ...) and didn't want to change too much after unlocking.
Don't ask about passing the SafetyNet check. I don't use Google Play Services so really can't answer this.
You can also do this yourself by following the instructions in the main Magisk thread. But I uploaded it as it's maybe of any use to somebody else that only needs a fast/simple (systemless) root solution.
DL-link:
https://www.androidfilehost.com/?fid=817550096634797229
Instructions:
Rename the downloaded image to boot.img and run the following commands from the same folder.
$ adb reboot bootloader
$ fastboot flash boot boot.img
$ fastboot reboot