Database Develop

[SAMSUNG][Android 6.x/7.x/8.x] SYSTEMLESS DevBase v2.1 | Encryption support

Hello
Do you remember my custom ROMs for older devices? Do you remember my "DevBase" and its idea? If not - please read hidden content below:
>> [ROM] DevBase for Note 3 (SM-N9005) <<
>> [ROM] DevBase for Note 4 (SM-N910F) <<
>> [ROM] DevBase for S5 (SM-G900F) <<
>> [ROM] DevBase for S5 Duos (SM-G900FD) <<
Since I created these custom ROMs - many things have changed. Main idea of my previous work was the ability to flash these ROMs over stock ROM without wipe data - to let users simply jump between official ROM and DevBase with most necessary modifications for advanced users. It was relatively simple to implement until Samsung introduced both: dm-verity's boot prevention + forced /data encryption (starting from S7/S7edge series). What does it mean? If you disable /data encryption - you are able to use TWRP like in older devices, you are able to flash custom ROMs available in this section, but you are not able simply switch to official stock ROM. Since I bought my S7 edge I realized, that the most reasonable way is to go in the "systemless direction".
Are you tired with traditional custom ROMs?
Do you miss custom ROMs but do not want to decrypt your device (for privacy/security reasons)? (!)
You are in the right place! I present you SYSTEMLESS DevBase - an SYSTEMLESS equivalent of my previous work (see hidden content above)
SYSTEMLESS DevBase is developed and physically tested on S7 Edge (G935F). However, it should work on ALL UNLOCKED SAMSUNG DEVICES running Android 6.x/7.x/8.x. Exynos? Snapdragon? NO MATTER !!!
Prerequisites:
- Samsung device running stock or stock-based Android 6.x or newer (7.x/8.x)
- Rooted device - Magisk v12+ or SuperSU v2.76+ installed in SYSTEMLESS mode (!)
- Stock, untouched /system partition (not mandatory, but recommended for OTA)
(!) WARNING (related to installing TWRP and/or rooting Nougat - e.g. ZPLN, DPLT or newer): There are confirmed reports that installing TWRP and/or rooting encrypted phones running stock Nougat causes bootloop (even if you just flash TWRP, without rooting). You will need to restore both - stock recovery and stock kernel (if you e.g. tried to flash SuperSU or other ZIP which might modify the kernel) to make your device bootable. You need to remove stock encryption (by formatting /data after rooting). If you need data encryption - you can easy re-encrypt already rooted device (by setting "KEEPFORCEENCRYPT" flag to "true" before (re)flashing Magisk or SuperSU).
SYSTEMLESS DevBase v2.0:
1. Benefits / main features:
- Works with encypted /data partition (**) (!)
- Working official OTA updates! (see Tips & Tricks - post #4)
- Does NOT perform any phisical modifications in /system
- Does NOT perform any additional changes/patches to the kernel
- Removed KNOX warnings (systemlessly removed SecurityLogAgent)
- It contains SYSTEMLESS BusyBox (bionic, the most stable and respected release)
- It allows you to easily modify most of files & apps in your /system - SYSTEMLESSLY (see Tips & Tricks)
2. Systemless Safe De-Bloat (more info below):
What does it mean and why is it called "safe"?
- ONLY apps available in stores will be systemlessly removed from the ROM, so you can easily (re)install any of these app if you like
- ONLY pre-installed system apps are will be systemlessly removed, DevBase installer never touch any updated app nor app installed manually from store
Thus, the following conclusions can be drawn:
1. If you install my SYSTEMLESS DevBase directly over working stock ROM - in most cases almost all these apps will remain untouched, because almost all apps have been updated already (stored on /data). But then you will be able to remove any useless app using the "Application manager" -> [Name_Of_App_To_Remove] -> MORE -> Uninstall updates. NOTE: App will disappear arter reboot and will be visible even in Titanium Backup!
2. If you perform "Wipe data" directly before installing SuperSU and my SYSTEMLESS DevBase (before you let to install app's updates) - then all apps listed below will be removed. If you would like to use any of these apps - just install it manually from appropriate store. Installed manually app will not be removed during the next DevBase update or re-install.
Removed apps list (depends on the device, should cover all devices starting from Galaxy S5):
ChatON
Chrome
Drive
Dropbox
EditorsDocs
Evernote
Excel
Facebook
FB Messenger
FB Pages Manager
Flipboard
Google+ / Photos
Group Play
Hangouts
Instagram
OneDrive
OneNote
PEN.UP
Play Books
Play Games
Play Movies
Play Music
Play Newsstand
PowerPoint
Skype
Smart Remote
WhatsApp
Word
NEW! Safe De-Bloat feature automatically detects and systemlessly removes apps not listed above, but present in your CSC package
3. Systemless CscFeature MOD (enabled some built-in, hidden features):
- Added shutter sound menu in Camera app
- Sending/receiving MMS without data on
- Show SMS/MMS sending time instead of receiving
- Added "Exit Internet" option to stock browser
- Added call button in Phone Logs (**)
- Added "Call/Message block" option in Settings
- Added symbols as secondary keys in Samsung keyboard (**)
- Added 4G/3G network support (master/slave SIM card - applies to Duos variants)
- Call Recording (added "Record" button, auto record calls - starting from Nougat)
- Enabled "Recent App Protection" feature
(**) may not work starting from Android 7.0 Nougat
Installation:
1. TWRP recovery:
- Tap "Keep Read Only" on the Welcome screen [extremely important for working OTA!]
- Open file using "Install" option (use extSdCard or OTG storage in case of encrypted /data)
- Confirm flash by swiping right
- Tap "Reboot System" (DO NOT wipe /cache after flashing in case of encrypted /data!)
2. FlashFire app (***):
- Open file using "Flash ZIP or OTA" option
- UNTICK "Mount /system read/write" [extremely important for working OTA!]
- Tap "FLASH"
NOTE1: One additional auto-reboot may be performed at first boot. It is not a bug (may be required for systemless build.prop support - see Tips & Tricks for more explanations)
NOTE2: Do not worry about red "mount /data failed..." messages displayed in TWRP in case of encrypted /data (installer will do the work anyway!)
(***) As far as I know - FlashFire is the only flashing tool with full access to /data during flash in case of encrypted devices (!). It is also the only tool which allows you to perform full backup/restore of partitions, including encrypted /data (!). It does NOT require custom recovery to work!
Credits:
@Chainfire for systemless SuperSU and a lot of inspiration
@topjohnwu for Magisk, another inspiration & some binaries used separately
Hit Thanks button if you like my work. If you really appreciate my work - feel free to buy me a beer

Download
>> SYSTEMLESS_DevBase_v2.1.zip <<
>> Recent SYSTEMLESS DevBase <<
Note:
Check MD5 sum BEFORE flash (useful TOOL), because flashing damaged or incomplete ZIP files can lead to issues! Correct MD5 sum is shown on the AndroidFileHost website while downloading.

Changelog
v2.1:
- Fixed potential "Google Play services" FCs in case of S8 or newer device(s)
v2.0:
- Initial support for devices using /system/omc CSC location (e.g. S8 / S8+ / Note 8)
- Added support for /system/preload as app location
- Other improvements & optimizations in the installer
v1.15:
- Added support for BINDSBIN mode (required by latest suhide) in case of SuperSU as root solution
v1.14:
- Added possibility to bypass all systemless mods by creating /cache/.disable_devbase file. It is usefull option especially for encrypted devices (without access to /data from TWRP) in case of you experienced bootloop due to placing a problematic MOD in /data/devbase/system/.. If /cache/.disable_devbase file exists then all systemless mods in ../app ../framework & ../piv-app will be moved to /data/devbase/system/.backup
- Backup all mods (to /data/devbase/system/.backup) instead of delete in case of major Android update has been detected
v1.13:
- Fixed bug with combination Magisk v15+ & SYSTEMLESS DevBase if we are trying to install one by one directly after wipe/format data
v1.12:
- Improved compatibility with Magisk v15+
v1.11:
- Fixed issues and improved compatibility with Magisk v14.5+
v1.10:
- Fixed not working /sbin support after clean installation of Magisk v14+, then SYSTEMLESS DevBase
v1.9:
- Improved/tuned compatibility with Magisk v13+ (which has been re-built from the scratch)
- Updated Magisk's binaries (e.g. resetprop function is now an applet available in magisk binary)
- Systemless BusyBox will be installed even with Magisk (since it has been removed from Magisk v13+)
v1.8:
- Fixed unroot2ota script to work while busybox is NOT in the $PATH (typical Magisk's case)
v1.7:
- Added support for /sbin via /data/devbase/sbin (you can only add a NEW item, e.g. script/binary/executable file). It can be an interesting feature for advanced users which would like to add custom commands, because /sbin is in the $PATH
- resetprop & unroot2ota now are placed in /sbin, in result unroot2ota command will natively work even with Magisk (without SuperSU)
v1.6:
- Improved/fixed Systemless Safe De-Bloat - now it should work in any case (even if enforceskippingpackages.txt file does not exist in your stock FW)
- In case of SYSTEMLESS DevBase update or re-installation - installer will not remove your custom entries in /data/devbase/system/build.prop and in *.xml files placed in /data/devbase/system/csc
- Added new features to Systemless CscFeature MOD: Allow 3G network mode in case of slave SIM card (Duos variant); Enabled "Recent App Protection" feature
v1.5:
- Added full support for MagiskSU as root solution. SuperSU is no longer the only available prerequisite
- Improved build.prop support in case of SuperSU as root solution, without magisk installed (seems like we can't rely on resetprop binary @ Android N)
- unroot2ota: removed SuperSU's sukernel dependency
v1.4:
- Improved/changed support for /data/devbase/system/build.prop file (uses @topjohnwu's resetprop binary)
- "ro.warranty_bit" & "ro.boot.warranty_bit" are set to "0" at boot -> fake KNOX 0x0 status (uses @topjohnwu's resetprop binary)
v1.3:
- Fixed CscFeature MOD (e.g. G920I case, now should work with all Samsung devices/variants)
v1.2:
- Added info in Settings/About device/Software info/Build number (can be overrided by editing /data/devbase/system/build.prop)
- unroot2ota: added ability to restore stock recovery using /system/recovery-from-boot.p file (no guarantee)
- unroot2ota: check /system partition for common modifications before unroot
- Minor changes & improvements in the shell code
v1.1:
- Added SYSTEMLESS support for /system/framework
- Added SYSTEMLESS support for /system/build.prop (overrides & additions)
- Added SYSTEMLESS BusyBox bionic (the most stable and respected release)
- Added major Android update detection (auto-remove mods for older API to prevent bootloops & FCs)
- Added logging to /data/devbase/last_boot.log (API & errors)
- Added SuperSU boot patcher version checker (exits su.d boot script if < 2.76)
- Added "Please DO NOT wipe /cache" warning in case of encrypted devices and TWRP recovery
- Minor changes & optimizations in the shell code
- Added SYSTEMLESS DevBase uninstaller
v1.0:
- Initial version

Tips & Tricks
1. OTA updates:
- Basically, the only thing you need to take OTA update is to perform "Full unroot" in the SuperSU app. However, a better way is to use "unroot2ota" terminal command, because this will not remove DevBase boot script from /su/su.d and the only thing you will need to re-activate SYSTEMLESS DevBase (and all your systemless MODs) after performing OTA update is just re-root your device with CF-Auto-Root.
- If you flashed custom recovery like TWRP - it is mandatory to restore your stock recovery (otherwise OTA will not work). You can do it using FlashFire app (the easiest way) - just open recovery.img file (extracted from your original FW) using "Flash firmware package" option, disable "Preserve recovery" option and then tap "FLASH". EDIT: Starting from version v1.2 there is a new "unroot2ota" feature which allow you to restore stock recovery using /system/recovery-fromm-boot.p file. There is no guarantee to perform it successfully (even if there is no error message) but in most cases it works well (tested on Nougat beta). Please go to recovery before you try to get OTA to check if you have stock recovery already after performing "unroot2ota" (if not - you need to use PC Odin to flash recovery.img packed in tar file).
- It is recommended to temporarily disable "Auto-update apps" in Play Store settings before you unroot your device. It will prevent updating applications covered by Safe De-Bloat list, as there apps will temporarily appear until you re-root the phone after performing OTA update.
Note (devices which use dm-verity): You should never allow /system modifications in TWRP, never allow to remount /system r/w in any app (e.g. Root Explorer, FlashFire, etc.) and never flash a ZIP file which could modify your /system or remount it r/w. Failure to follow these recommendations will break dm-verity verification and will cause, that your device may not be able to boot with the stock kernel (you will need to re-flash your original FW using PC Odin to make your device bootable).
UPDATE: Due to the fact that installing TWRP and/or rooting encrypted phones running stock Nougat is not possible without format /data - the above described advantages applies to stock ROMs based on Android up to 6.0
2. Making your own modifications:
- You can systemlessly replace any existing system app by modded one. Just put modified app to /data/devbase/system/app or /data/devbase/system/priv-app and then reboot your device
- You can systemlessly replace jar or apk in /system/framework. Just put modified one to /data/devbase/system/framework and then reboot your device (NOTE: framework support has been added for advanced users -> there is high risk of bootloop if you do something wrong!)
- You can systemlessly add or override any line in /system/build.prop. Just put (only new or changed) line to /data/devbase/system/build.prop and then reboot your device (NOTE: one additional auto-reboot may be performed if /data/devbase/system/build.prop file has been added, modified or removed (SuperSU case). It is not a bug - it is required for the changes in /data/devbase/system/build.prop to take effect!)
- You can systemlessly replace any existing file in /system/csc and /system/etc (but NOT in subdirectories). Just put modified copy of a file to /data/devbase/system/csc or /data/devbase/system/etc and then reboot device
Limitations: original app or file MUST physically exist with the same name in /system, you can NOT add a new app or file this way!
Example 1 (Ad-Blocking): Download the latest Ad-Blocking ZIP installer from THIS thread. Extract "hosts" file (placed in /system/etc inside ZIP file), then copy it to /data/devbase/system/etc, set rw-r--r-- (644) permissions and then reboot device
Example 2 (modded SamsungCamera6): Create "SamsungCamera6" directory in /data/devbase/system/priv-app and then put modified "SamsungCamera6.apk" file into it. Set rwxr-xr-x (755) permissions to "SamsungCamera6" directory, rw-r--r-- (644) permissions to "SamsungCamera6.apk" and then reboot device
Example 3 (De-Bloating a bit more): You can just create empty directories in /data/devbase/system/app (or priv-app) corresponding to applications in /system/app (or priv-app). Alternatively (more advanced method), you can add an app to modded enforceskippingpackages.txt file (you can find it in /data/devbase/system/etc or /data/devbase/system/csc_contents, depending on the original location in /system) and increase number in the 1st line. Second method should not be used by beginners (without a basic knowledge related to UNIX text format)
3. How to manually maintain the newest ROM version:
If you do not care about OTA - you can manually update your device to the newest ROM available @ Sammobile, keeping your original CSC (you need multi-file original FW, I mean separate files for BL/AP/CP/CSC). You need to download 2 ROMs: ROM with the newest changelist and the latest ROM containing your original CSC. Extract both and open in PC Odin BL/AP/CP files from the ROM with highest changelist but open CSC file from the ROM containing your CSC (I recommend to use HOME_CSC_* file to avoid auto-wipe-data). Flash such "mix", re-root and enjoy

Optional MODs
I put some of my favorite MOD's. These modifications I have done personally using (bak)smali tools - these are NOT "borrowed" from other custom rom, nor from someone else's thread (thanks to @majdinj & @tdunham for their excellent modding guides). All files are FlashFire / TWRP flashable ZIPs.
These MODs are compatible with SYSTEMLESS DevBase - installer will try to detect if your /system has been moddified (or not) already. If the installer will not detect any popular /system modifications like SuperSU / busybox / Xposed (installed to /system) then will try to install app systemlessly to /data/devbase/system/(priv-)app
1. Modified Camera app:
- Full functionality of the Camera app in low battery
2. Modified Messages app:
- Disabled SMS delivery notifications (*)
(*) If you long press a message you can still check if the message has been delivered or not, we do not need to see and hear notifications for every sms. It's annoying to me!
>> MODs for G935F (Marshmallow) << (**)
>> MODs for G935F (Nougat) << (**)
(**) Original apps come from stock ROM for G935F, but these MODs should work on all S7 flat & edge variants (Exynos based)
In case of MODs installed to /system - you can restore original apk using backup stored in /data/alexndr/backup

Incredible work, man! Thanks

I'm HAPPY to see you in this Forum with an S7edge !

@_alexndr
Congrats mate! Great job I will test it in a few days
# 1 question
What about framework folder support with modded files ?
# 2 question
Modded deodex apps putted in /data/devbase/system folders will work on odex system ?
For example:
/data/devbase/system/priv-app/SystemUI/SystemUI.apk
will be deodexed
but orginal one:
/system/priv-app/SystemUI/SystemUI.apk
will be odex (with arm folders)
# 3 question
For example if I put systemui.apk the modded will be run and original no ? Or they collaborate toggether ?
Edit:
If I correct understand examples they are colaborate
# 4 question
system/etc/permissions files not supported too ? For exapmle platform.xml
••••
This tool have a BIG potential to be the greatest !
Have a nice day

ambasadii said:
@_alexndr
Congrats mate! Great job I will test it in a few days
# 1 question
What about framework folder support with modded files ?
# 2 question
Modded deodex apps putted in /data/devbase/system folders will work on odex system ?
For example:
/data/devbase/system/priv-app/SystemUI/SystemUI.apk
will be deodexed
but orginal one:
/system/priv-app/SystemUI/SystemUI.apk
will be odex (with arm folders)
# 3 question
For example if I put systemui.apk the modded will be run and original no ? Or they collaborate toggether ?
Edit:
If I correct understand examples they are colaborate
# 4 question
system/etc/permissions files not supported too ? For exapmle platform.xml
����
This tool have a BIG potential to be the greatest !
Have a nice day
Click to expand...
Click to collapse
#2: Deodexed apps works great in odexed rom, but odexed apps will not work at all in case of deodexed framework!
SYSTEMLESS DevBase uses bind mounts so entire /system/priv-app/SystemUI directory (and its content) will be virtually replaced by /data/devbase/system/priv-app/SystemUI => it means you will not see oat/arm directory => entire app will act as deodexed in /system/...
See attached screenshots - first is with moded SamsungCamera5 present in /data/devbase/system/priv-app, second is after deleting /data/devbase/system/priv-app/SamsungCamera5 (and reboot)
Now it is good time to answer #1: With framework I intentionally dropped possibility to replace systemlessly files in .../framework (for security reasons @ to avoid unintentional bootloops). Imagine that you "systemlessly" replace ../framework/oat directory by empty one => then all jars corresponding to *.odex files in oat/arm(64) will immediately require classes*.dex files inside jars (otherwise will not work). Even if you replace entire framework by deodexed (with classes.dex inside jars) -> as I stated above (answer #2) -> almost all apps in /system/app & priv-app will stop working as almost all apps are originally ODEXED.
Imagine also that you leaded device into bootloop by replacing files in framework AND you have encrypted /data. There is no easy way out for normal users (which are not able to play with "fake" /cache/su.img to make workaround matched to the problem) they will not be able just remove files (causing the problem) from /data/devbase/system/framework using TWRP
In sum - thats why I have not introduced such possibility for normal users, but you as the DEV may extend this idea and try to systemlessly replace entire framework, app & priv-app by deodexed content (I have not tested it personally, IMO it does not worth the effort)
#3: The answer is now clear from the answer to question #2 - modded will run and original will NOT (original will "virtually disappear")
#4: It is easy to extend support for etc/permissions/* files by editing 0000000devbase, I will think about it

Now almost everything is clear
so for example if i put /data/devbase/system/framework/services.jar and delete from system/framework/oat/arm64/services.odex file should work ?
add support for etc/permissions/* files to fix ext-card permissions (platform.xml)

ambasadii said:
Now almost everything is clear
so for example if i put /data/devbase/system/framework/services.jar and delete from system/framework/oat/arm64/services.odex file should work ?
add support for etc/permissions/* files to fix ext-card permissions (platform.xml)
Click to expand...
Click to collapse
The only way to "virtually remove" files using this method is "fake" (e.g. empty) parent directory. Another way is to create "fake" file with same name (but size 0 bytes).
There is a chance that it will work for services.jar - but such "fun/play" is only for advanced DEVs, like you :good: you need to extend support for framework and subdirectories in 0000000devbase su.d script. Then you can try to systemlessly replace jar by deodexed&modded one in /data/devbase/system/framework... and odex file by "fake 0 sized" odex in /data/devbase/system/framework/oat/arm64/...
EDIT: @ambasadii, there is no need to "remove" (whatever it means) odex file as it will be ignored in case of jar or apk contains classes*.dex inside

Ok I will test it
Sent from my SM-G935F using XDA-Developers mobile app

_alexndr said:
you need to extend support for framework and subdirectories in 0000000devbase su.d script. Then you can try to systemlessly replace jar by deodexed&modded one in /data/devbase/system/framework...
Click to expand...
Click to collapse
correct ?
Code:
if [ -d "/data/devbase/system/framework" ] ; then
for i in `ls /data/devbase/system/framework` ; do
mount -o bind /data/devbase/system/framework/$i /system/framework/$i 2>/dev/null
done
fi
if [ -d "/data/devbase/system/etc/permissions" ] ; then
for i in `ls /data/devbase/system/etc/permissions` ; do
if [ -f "/data/devbase/system/etc/permissions/$i" ] ; then
mount -o bind /data/devbase/system/etc/permissions/$i /system/etc/permissions/$i 2>/dev/null
fi
done
fi
EDIT: @ambasadii, there is no need to "remove" (whatever it means) odex file as it will be ignored in case of jar or apk contains classes*.dex inside
Click to expand...
Click to collapse
good news, remove it means delete

ambasadii said:
correct ?
Code:
if [ -d "/data/devbase/system/framework" ] ; then
for i in `ls /data/devbase/system/framework` ; do
mount -o bind /data/devbase/system/framework/$i /system/framework/$i 2>/dev/null
done
fi
if [ -d "/data/devbase/system/etc/permissions" ] ; then
for i in `ls /data/devbase/system/etc/permissions` ; do
if [ -f "/data/devbase/system/etc/permissions/$i" ] ; then
mount -o bind /data/devbase/system/etc/permissions/$i /system/etc/permissions/$i 2>/dev/null
fi
done
fi
Click to expand...
Click to collapse
Basically correct but you need to add bind mounts only for files (just in case)
I will send you today new (pre-release v1.1) version with "slightly tuned code" and with support for framework
good news, remove it means delete
Click to expand...
Click to collapse
Nice joke :silly: "whatever it means" => FYI => it may also mean bind mounts with files (0 bytes size)

Welcome to the S7 bro

Hi alexndr
I love you from 9005 to now.
Plz add a option in cmera mod,that under i geting 60fps video,i can get pic.
Mean, camcorder 60fps and camera pictures together .
I cant write eng.plz exercise me.
Sent from my SM-G935F using Tapatalk

Awesome to see you here! Thanks @_Alexandr
Gesendet von meinem SM-G935F mit Tapatalk

Nice to see a familiar face in the S7 (E) section! Good luck with all your plans here.
Verstuurd vanaf mijn SM-G935F met Tapatalk

Nice to find you here Alexandr, been using your Roms on my old note 3 about 8 months ago and they were the most stable "custom Roms". But then you were providing a full unmodified ROM with root access, can you do something like this here for those of us that wish it? I personally don't have access to a PC so I can't flash newer firmwares with Odin, so I'm stuck using flashable ROMs.

It is possible to install magisk and work hide magisk for apps, for example bank apps?

Question Regarding twrp

Can anybody explain why isn't there a wipe system option in the twrp in advanced wipe section...
In earlier devices that I've used ,the wipe system option has always been there.
Or is this happening only in the nebrassy recovery for sweet?
just a query!

Same question.. Can an expert answer this? Thanks

In my opinion normally it's not needed and for newbie it's dangerous

- I'm no expert at all, but missing option for wipe /system is not there for a reason (on my previous surya device (when it was launched) the first builds of recoveries had option to wipe /system, but people find out very quickly that wipe /system on super partition is not a good idea, very few ended with bricked devices, after that wipe /system was removed from recoveries)
- on A9 /system had its own partition and very simply put - it was easy to manipulate, situation changed with A10 (A11), when /system become like virtual partition (along with /vendor, /product and whatever manufacturer of the phone decided to put there) or directory if you like in super partition and its RO by default (unless flashing to it, you can't manipulate it directly on file system level - every wipe option in recovery means you simple delete some files here and there and you can't delete files on Read Only virtual partition)
- problem is much more complicated and I'm explaining it as I understand it - I can be wrong on detail, but this is roughly the situation
- if you're active tester and/or flashaholic who likes to test ROMs as they are released it is a good idea to flash (before you flash new custom ROM) either recovery version of latest MIUI available for your device (or maybe Xiomi.eu ROM based on that) - inclueded installation scripts will clean your super partition to the certain level - so you can for example flash stubborn ROM, that refused boot so far, etc. - its not wipe and I agree - clean slate is always better, than breadcrumbs of the previous flashes left here and there, but here we are...
- sure - direct control over /system part of super partition would be nice - and I hope that one day TWRP or OFOX devs will tame that "super" beast and return wipe /system when it will be safe for us to use it as before...

Question Could not mount system in RW mode. Can you?

Did anybody had a luck of getting RW on C25s ? If so, what was the procedure? Of course, I'm aware of shared_blocks feature, which I removed for all system partitions already.
It's funny, but even if flag rw is set as a mounting option in both fstab files - you'll never get RW for any system partitons. You'll never see RW not only for system / vendor / odm but for all my_ partitions - all of them fail to mount in RW.
And no, it's not funny, it's weird.

vp1117 said:
Did anybody had a luck of getting RW on C25s ? If so, what was the procedure? Of course, I'm aware of shared_blocks feature, which I removed for all system partitions already.
It's funny, but even if flag rw is set as a mounting option in both fstab files - you'll never get RW for any system partitons. You'll never see RW not only for system / vendor / odm but for all my_ partitions - all of them fail to mount in RW.
And no, it's not funny, it's weird.
Click to expand...
Click to collapse
all partitions are set to RO because of dynamic partitions

gianonceu said:
all partitions are set to RO because of dynamic partitions
Click to expand...
Click to collapse
This does not answer my question how to get RW on this particular model. Probably, you know that RW can be easily achieved on other realme phones. Actually, on dozens of phones with super partition where we're bound to have dynamic partitions.
Also, when you say "...partitions are set to RO..." what exactly you mean? Set by whom? To repeat: I've manually removed shared_blocks features on all super sub-partitions and then re-created super. When I flash it, I can clearly check in TWRP that tune2fs -l does not show shared_blocks anymore. So, who has set partitions to RO?
If you know what mechanism of android sets RO on super sub-partitions with shared_blocks removed - please share your knowledge.

Well, judging by no responses the question appears to be of almost zero interest for forum members. Is this the case?

I'm glad to confirm that RW on all super partitions can be easily achieved if RMX3195 runs A12.
However, you'll need to convert erofs dynamic partitons of super to ext4 ones. I did it manually in linux. After partitions are converted you also will have to make certain effort to remove bloatware from ext4 partitions. If bloatware isn't removed then total size of ext4 partitions will exceed max size of super and you will not be able to re-construct super.
Funny enough, I failed to get RW on A11.

so i have this problem yet

Congratulations @vp1117 for successfully making your device RW
Did you use the Yuki guide that's basically a copy paste from the thread in my signature (with the addition of a make_ext4fs binary) ? Where did you find those selinux context files for each subpartition of super to plug into the make_ext4fs binary? Without the proper context files the magic is not going to work right?
Thanks!

vp1117 said:
I'm glad to confirm that RW on all super partitions can be easily achieved if RMX3195 runs A12.
However, you'll need to convert erofs dynamic partitons of super to ext4 ones. I did it manually in linux. After partitions are converted you also will have to make certain effort to remove bloatware from ext4 partitions. If bloatware isn't removed then total size of ext4 partitions will exceed max size of super and you will not be able to re-construct super.
Funny enough, I failed to get RW on A11.
Click to expand...
Click to collapse
Can u guide me in same issue I'm also stuck paid no problem

lebigmac said:
Congratulations @vp1117 for successfully making your device RW
Did you use the Yuki guide that's basically a copy paste from the thread in my signature (with the addition of a make_ext4fs binary) ? Where did you find those selinux context files for each subpartition of super to plug into the make_ext4fs binary? Without the proper context files the magic is not going to work right?
Thanks!
Click to expand...
Click to collapse
Hi!
No, I did not use anybody's guide.
I just took a file (product.img, if I recall it correctly) from the old firmware (it was in ext4 format since it was A11 firmware where erofs fs was not implemented yet), mounted it in linux and then just copied into it all files from system_ext.img. Repeated same excersise for my_bigball.img, my_heytap.img, my_preload.img, my_stock.img subpartitions. All contexts were preserved by using proper option of cp command.
And no, I never used make_ext4fs binary.
I made several attempts to re-construct super.img, and I was able to make RW not only for above mentioned 5 subpartitions, but for all 13 subpartitions of super. However, upon some thinking, I decided that I did not need RW for the rest of 8 subpartitions as I did not find much of bloatware in them. So, to make things easier for me I have now RW only for system_ext / my_bigball / my_heytap / my_preload / my_stock. The rest of subpartitions remain in erofs format.
The main riddle for me is that why I failed to achieve RW using same procedure when my RMX3195 ran A11... But I do not plan to return to A11, so this question is already a history for me.

vp1117 said:
Hi!
No, I did not use anybody's guide.
I just took a file (product.img, if I recall it correctly) from the old firmware (it was in ext4 format since it was A11 firmware where erofs fs was not implemented yet), mounted it in linux and then just copied into it all files from system_ext.img. Repeated same excersise for my_bigball.img, my_heytap.img, my_preload.img, my_stock.img subpartitions. All contexts were preserved by using proper option of cp command.
And no, I never used make_ext4fs binary.
I made several attempts to re-construct super.img, and I was able to make RW not only for above mentioned 5 subpartitions, but for all 13 subpartitions of super. However, upon some thinking, I decided that I did not need RW for the rest of 8 subpartitions as I did not find much of bloatware in them. So, to make things easier for me I have now RW only for system_ext / my_bigball / my_heytap / my_preload / my_stock. The rest of subpartitions remain in erofs format.
The main riddle for me is that why I failed to achieve RW using same procedure when my RMX3195 ran A11... But I do not plan to return to A11, so this question is already a history for me.
Click to expand...
Click to collapse
Bro can u try something for me?
In your root dir have folder with name "proc" can u go inside and cut file and move to sdcard or any other modifications to check whether this past also editable or not?

System encrypted, /dev/block is read-only

Hi, I have a redmi note 9 that I wanted to mod but I had a lot of problems modding it. I initially installed crDroid 8.7 but the control center animation was lagging and the battery drains fast, so I decided to change the ROM with Project Elixir (Android 12 all ROMs). I saw that crDroid 8.9 came out (September 22, 2022) and there had been some notable changes, as the battery did not run out anymore the animations were fluid, but i was not able to get working google apps.
I tried everything and it wasn't right. (Nik, OpenGapps, MTG nothing) indeed I installed the gapps I had on 8.7 and them didn't work .. So I decided to move to pixel experience android 12 but I had these problems:
On all the roms that I have installed (except I think MIUI) the system is encrypted. I tried flashing a zip, via commands, via recovery but nothing the system is encrypted. I can't access it and in addition I wanted to change the bootanimation but I can't move the zip because it says it's read only and following these commands too I couldn't do it:
adb root
adb disable-verity
adb reboot
adb remount
adb shell
mount -o rw,remount /system
for these commands i also used ADB Sideload (ofc) but also some zips
It says the /dev /<number>/block is read-only and I have not been able to unlock it. (I tried with all these recoveries: TWRP, SHRP (SkyHawk, OrangeFox [UNOFFICIAL but is only for A11]). (If I go from TWRP to sdcard / I have all the files encrypted. I have the phone rooted with magisk.
In addition, I also had problems formatting the phone because the system with both TWRP and SHRP was not deleted or if I restarted the phone after formatting the ROM would open again so to format it I used Pixel Experience which has worked very well so far.

But custom rom already have ability to rw
Anyway you're lucky there thread available google it like
Universal method to get rw

Idk. I have installed Project Elixir, crDroid and this Pixel Experience and are encrypted.
I already googled it....

/dev/* will be always read-only.

And how i can modify the boot animation? Files are encrypted and the zip is in /system/product/media/.zip

/dev/ and /system/ are not same.
Stock MIUI is system read-only.
If you want to mount system as read-write, you need "universal mount system r/w" by @lebigmac
[Closed] Universal SystemRW / SuperRW feat. MakeRW / ro2rw (read-only-2-read/write super partition converter)
Welcome to the one and only, the original, universal, System-RW / Super-RW feat. Make-RW / ro2rw (read-only-2-read/write super partition converter) by lebigmac Also known as: THE-REAL-RW, FULL-RW, EXT4-RW, EROFS-RW, EROFS-2-RW, F2FS-RW...
forum.xda-developers.com

Oh ok, it will work on A12?

I'm not sure.

Ok so tried flashing systemrw_flashable (Universal RW) with sideload bcs i have crypted files.
This is the error that it gave me:
Extracting ...
There was an error extracting the file. Please install unzip and try again.
I tried flashing with SHRP (TWRP based) bcs twrp can't work with adb sideload (for me).
Edit: searched on xda the problem, i installed the BusyBox module in magisk (From Fox Modules Manager) but nothing to do, still same error.

Deltwin said:
Oh ok, it will work on A12?
Click to expand...
Click to collapse
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!

lebigmac said:
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
Click to expand...
Click to collapse
But how can be you make sure without some beta testers you neef guys like me and this op who have device in hand to test it and give you feedback

lebigmac said:
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
Click to expand...
Click to collapse
Oh so it cant work in sideload... Good tip if it will work u made a very good script

To be honest I've never used this sideload feature before... What are the advantages of sideloading versus flashing the .zip as usual?
Mr Hassan said:
But how can be you make sure without some beta testers you neef guys like me and this op who have device in hand to test it and give you feedback
Click to expand...
Click to collapse
That's a good idea. I should release an open beta before releasing the final program.
That way we can make sure it works on as many devices as possible

lebigmac said:
To be honest I've never used this sideload feature before... What are the advantages of sideloading versus flashing the .zip as usual?
That's a good idea. I should release an open beta before releasing the final program.
That way we can make sure it works on as many devices as possible
Click to expand...
Click to collapse
Thanks for appreciating the idea
Hope we'll get beta soon but is there any idea date how many days still need to release it
Ok let me show my progress
I make my vendor sys odm to ext4
And ser the logs according to logs
I have rw now
OnePlus8:/ # mount | grep "dm-0"
/dev/block/dm-0 on / type ext4 (rw,seclabel,relatime)
OnePlus8:/ # mount | grep "dm-19"
/dev/block/dm-19 on / type ext4 (rw,seclabel,relatime)
OnePlus8:/ # mount | grep "dm-3"
But the weird thing is still not able to edit
Any file in these parts.

lebigmac said:
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
Click to expand...
Click to collapse
How i can run ur script directly from android?
Like on magisk?

Deltwin said:
How i can run ur script directly from android?
Like on magisk?
Click to expand...
Click to collapse
Hi. Please check the Manual Installation and Examples section of the thread in my signature
And if you're running Android 12+ don't forget to disable the sdkCheck() function in the systemrw.sh script file @ line # 425 like this #sdkCheck
It should work if your only problem is the shared_blocks read-only feature. If your device got the new erofs read-only protection feature then you must wait for next version of my script or try your luck one of the copycat imitations that are floating around.
Good luck!

So after an hard brick at work (so i leaved it for 5 hours with redmi logo on lol) and after many steps i reinstalled MIUI with root... it's running A11 so how i can install it? I need to disable the sdkCheck? I think no if you need it on A12...
Second question i need to flash it before the first boot or i can do it after the first boot?

Deltwin said:
So after an hard brick at work (so i leaved it for 5 hours with redmi logo on lol) and after many steps i reinstalled MIUI with root... it's running A11 so how i can install it? I need to disable the sdkCheck? I think no if you need it on A12...
Second question i need to flash it before the first boot or i can do it after the first boot?
Click to expand...
Click to collapse
I thought hard bricks were unrecoverable?
If your Xiaomi device is running Android 10 or 11 then you don't need to disable the sdkCheck() function in my old script.
Ok here are all the necessary steps in chronological order for you
unlock bootloader
flash stock ROM
install systemrw_1.32
root
debloat
customize
enjoy

No it's possible, i tought not but here i am with my redmi note 9..
jk apart i unbrick with SP Flash tool but i had other problems like NVRAM warning (it fixed automatically with updates idk lol..) and the IMEI was deleted but fortunately i had a flashable backup..
I need to flash the stock rom? I have pixel experience with A12/13
Edit: I tried to flash it (i have the file on the microSD) but it gave me this error:
There was an error extracting the file. Please install unzip and try again.

Well my script was designed for stock A10, A11 ROMs ( or A12 if you're lucky and your device only uses the infamous shared_blocks read-only feature + you must disable sdkCheck() function in script itself ) but I don't see why it shouldn't work on a custom ROM as well
Ok let me try this again but only because it's you
Boot phone into Android OS and make sure it's properly rooted
download the systemrw_1.32_BUNDLE_proper.zip and extract it
extract the systemrw_1.32_flashable.zip
copy the systemrw_1.32 folder into /data/local/tmp/ on your phone
open adb shell or terminal app and type
Bash:
adb shell
su
cd /data/local/tmp/systemrw_1.32
chmod +x ./systemrw.sh
./systemrw.sh in=`realpath /dev/block/by-name/super` size=50
Good luck!

Question Xiaomi 11T Pro on TWRP backup failed on backing up Super (system system.ext product vendor odm) ....

Mi 11T Pro TWRP Backup failed twice on same area ........ Backing up Super (system system_ext product vendor odm)...
I did twice and same spot that failed miserably and I also copied just a small portion of the recovery log that fail:
Backing up Super (system system_ext product vendor odm)...
I:Reading '/dev/block/by-name/super', writing '/usb_otg/TWRP/BACKUPS/5bb27ae4/2022-12-27--06-03-40/super.emmc.win'
I:Error writing destination fd (Operation not permitted)
Backup Failed. Cleaning Backup Folder.
Running on the latest TWRP twrp-3.7.0_12-v6.5_A12-vili-skkk and rooted with lastest Magisk v25.2 with safety net passed.
Any advice is highly appreciated and thanking in advance - -

NDbluewee said:
Mi 11T Pro TWRP Backup failed twice on same area ........ Backing up Super (system system_ext product vendor odm)...
I did twice and same spot that failed miserably and I also copied just a small portion of the recovery log that fail:
Backing up Super (system system_ext product vendor odm)...
I:Reading '/dev/block/by-name/super', writing '/usb_otg/TWRP/BACKUPS/5bb27ae4/2022-12-27--06-03-40/super.emmc.win'
I:Error writing destination fd (Operation not permitted)
Backup Failed. Cleaning Backup Folder.
Running on the latest TWRP twrp-3.7.0_12-v6.5_A12-vili-skkk and rooted with lastest Magisk v25.2 with safety net passed.
Any advice is highly appreciated and thanking in advance - -
Click to expand...
Click to collapse
You have rooted the phone and you must have seen that even with root the system partitions remain in read only which means that you cannot restore the system with the Twrp which must have write permission.

NOSS8 said:
You have rooted the phone and you must have seen that even with root the system partitions remain in read only which means that you cannot restore the system with the Twrp which must have write permission.
Click to expand...
Click to collapse
Thanks @ Noss8
Yes, I do understand this part however, If I use PartitionBackups to back up all the files around 6.7 GB ..... the question is can I restore through PartitionBackup in future? Thank again for the piece of advice!

NDbluewee said:
Thanks @ Noss8
Yes, I do understand this part however, If I use PartitionBackups to back up all the files around 6.7 GB ..... the question is can I restore through PartitionBackup in future? Thank again for the piece of advice!
Click to expand...
Click to collapse
I don't know this app.
The system on devices with A/B partitions with A12 or A13 remain in Read only.
Try to restore only the data without the system/vendor/etc.
Did you remove security on the lock screen and reboot the system before your backup?
This has the effect of decrypting your data.
Micloud can also back up your data, apps (not all and without settings), mms, sms, photo, music, configuration settings, but the free version is limited to 5GB.
There is also backup on PC with Micloud, just a folder to cut / paste.

NOSS8 said:
I don't know this app.
The system on devices with A/B partitions with A12 or A13 remain in Read only.
Try to restore only the data without the system/vendor/etc.
Did you remove security on the lock screen and reboot the system before your backup?
This has the effect of decrypting your data.
Micloud can also back up your data, apps (not all and without settings), mms, sms, photo, music, configuration settings, but the free version is limited to 5GB.
There is also backup on PC with Micloud, just a folder to cut / paste.
Click to expand...
Click to collapse
Thank again @ NOSS8
Yes, I did removing all my security passwords on the lock screen before doing all the backups.
The Twrp was good where I managed to backup everything except the system while the PartitionBackup did backup everything!
Yes, I do fairly backup only folders under Micloud as only 5GB of storage only!
Thank you