FullOTA-MF vs FullOTA-MF-PV - Huawei Mate 9 Questions & Answers

When choosing files from FF or to download for HWOTA or other stuff which one should we choose since both work?
And what is the difference between these files/packages?

no one knows ?

According to team MT. PV means point version and is used to move between android versions e.g. 7 to 8. MF means multi file e.g. more than one update is contained in the package.

Related

Firmware files

Sometimes we see that some firmware contains 3 files, whereas some contains 2 files.
1. What's the difference between them?
2. Some firmwares can be flashed through TWRP, but some fails. Why?
3. What's the difference between FullOTA-MF and FullOTA-MF-PV?
If you do just a tiny bit of research whether it's here on XDA or Google you'll have your answers. You're breaking the literal first rule of XDA. SEARCH FIRST.
SirDarknight said:
Sometimes we see that some firmware contains 3 files, whereas some contains 2 files.
1. What's the difference between them?
2. Some firmwares can be flashed through TWRP, but some fails. Why?
3. What's the difference between FullOTA-MF and FullOTA-MF-PV?
Click to expand...
Click to collapse
1. The only firmwares with two files are PV firmwares. For example, B394 for FRD-L09 is PV and has two files. The Firmware itself is not different. It has the same files as those firmwares which have their data split into two separate files, a public data zip (which as the name suggests is a generic data zip applicable for all models) and a region data zip (like hw_usa or hw_eu) which is intended only for a specific model / region.
3. FullOTA-MF are complete firmware files. It contains all patches released for a specific Android version and is thus also called as the firmware which contains all service packs. The OTA firmwares are one specific service pack only. So let's say you are on B360, you can use a FullOTA-MF package to straight upgrade to B504 but if you take the OTA route, you have to take all updates released after B360 one by one until you reach B504.
The PV packages, known as Point Version are used to upgrade from an older Android version to a newer one, say from 6.0 to 7.0. That's the reason why changelogs for PV contain the line 'your device will be upgraded to Android 7.0, bla bla bla'. Other than that they are same as MF packages and can be used to jump straight to a newer firmware.
2. Why you can PV through TWRP, I suspect that's because PV allow you to upgrade to newer Android versions and this is for the sake of compability. EMUI 4 doesn't has the same authentication algorithm as EMUI 5.
Apart from PV all other firmware cannot be flashed through TWRP since they were not intented to be flashed using TWRP the first place. They fail authentication which TWRP doesn't supports. That's why we have HuRupdater which has its own update binary that allows you to flash those packages by bypassing the authentication checks.
hackslash said:
1. The only firmwares with two files are PV firmwares. For example, B394 for FRD-L09 is PV and has two files. The Firmware itself is not different. It has the same files as those firmwares which have their data split into two separate files, a public data zip (which as the name suggests is a generic data zip applicable for all models) and a region data zip (like hw_usa or hw_eu) which is intended only for a specific model / region.
3. FullOTA-MF are complete firmware files. It contains all patches released for a specific Android version and is thus also called as the firmware which contains all service packs. The OTA firmwares are one specific service pack only. So let's say you are on B360, you can use a FullOTA-MF package to straight upgrade to B504 but if you take the OTA route, you have to take all updates released after B360 one by one until you reach B504.
The PV packages, known as Point Version are used to upgrade from an older Android version to a newer one, say from 6.0 to 7.0. That's the reason why changelogs for PV contain the line 'your device will be upgraded to Android 7.0, bla bla bla'. Other than that they are same as MF packages and can be used to jump straight to a newer firmware.
2. Why you can PV through TWRP, I suspect that's because PV allow you to upgrade to newer Android versions and this is for the sake of compability. EMUI 4 doesn't has the same authentication algorithm as EMUI 5.
Apart from PV all other firmware cannot be flashed through TWRP since they were not intented to be flashed using TWRP the first place. They fail authentication which TWRP doesn't supports. That's why we have HuRupdater which has its own update binary that allows you to flash those packages by bypassing the authentication checks.
Click to expand...
Click to collapse
Huge Thanks, brother!! You're truly helpful.

Cannot change from Chinese to European build. Help!

I have tried many things, HiSuite, MTT (fails to download the entire update file), and both to PE-TL10C432B571 and previous versions of the European build.
Current build is the Chinese build of PE-TL10V100R001CHNC00B260
It won't do OTA obviously, but I can't convince it to change to anything else at all ?
What must I do to get this to the 571 build or better.?
I keep getting the screenshot which I cannot attach when it try the manual update and pointing it to the /dload update.app
Many thanks. After two days of struggling!
" Software install failed " (image cannot upload)
Get online help from www emui com slash emotionaldownload.php?mod=restore
Press Power Key to confirm

Looking for June-updated boot image

I want to avoid configuring the system from scratch and thus need to recover the official boot image for PPIS29.65-51-5 for the European version (reteu), which has been available since few days ago.
Does anyone know where to find it?
Stockrom[1] only has the Brazilian version (retbr) and lolinet[2] only has versions up to PPIS29.65-51-3. The Telegram Moto Updates Tracker[3] shows the update, but the download does not work and the older MotoOTA script[4] does not work neither (or I am entering incorrect information) and the newer MotoOTA script[5] needs the build guid, which I do not seem to be able to get from fastboot or TWRP.
If you have a matching model and version, could you please get the boot image[6] and put it somewhere?
[1]: stockrom.net/2020/06/xt2019-2-retbr-9pie-ppis29-65-51-5.html
[2]: mirrors.lolinet.com/firmware/moto/doha/official/RETEU/
[3]: t.me/s/motoupdatestracker?q=%23doha+Retail+Euro+PPIS29.65-51-5
[4]: motoota.lolinet.com
[5]: motoota.lolinet.com/guid.php
[6]: android.stackexchange.com/a/190102
Update
I learned that the former most recent version [7] can be used to find out the guid inside of oem.img inside of that zip file:
ro.mot.build.guid=7d7b4268f01b080
Using that information [5] can be used to download Motorola's OTA zip file. However, that zip file seems to be some kind of patch format (only 72 MB instead of the typical 1.9 GB) not including a (complete) boot.img. As I do not know the file format, I can't patch the new boot.img myself.
[7]: mirrors.lolinet.com/firmware/moto/doha/official/RETEU/XT2019-1_DOHA_RETEU_9.0_PPIS29.65-51-3_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip

Realme X50 Pro 5g GSI (RMX2071)

Hi everyone, I am a RMX2071 owner and I was experimenting with GSI images, I have installed the AOSP 10 GSI (AOSP 10.0 v222) Source: https://github.com/phhusson/treble_experimentations/releases/tag/v222
Seems like it works except for the fingerprint (it doesn't work) and the camera that could be better. I'm not a developer nor I'm familiar with Android modding. I have bricked my phone several times during the attempt. This is not an advice or guide, everything you do is at your own risk.
I had unlocked bootloader and TWRP (Source: https://forum.xda-developers.com/realme-x50-pro/how-to/recovery-lr-team-twrp-3-4-1b-0616-t4123353)
This is what I did:
I have downloaded the latest firmware for my device from realmeupdater (https://realmeupdater.com/)
It was an OZIP file, I have unpacked with this tool (https://github.com/bkerler/oppo_ozip_decrypt)
Now I have a zip file
I have downloaded a GSI .img image (I have tried many, the one listed is the one that works best for now)
I have used this tool (https://github.com/xpirt/img2sdat) to convert .img to three .dat files: system.new.dat, system.patch.dat, system.transfer.list
I have used this other tool (https://github.com/VarunSaiTeja/Brotli-Rom-Manager) to convert system.new.dat into system.new.dat.br
I have deleted this three files from the the official rom zip, using 7zip: system.new.dat.br, system.patch.dat, system.transfer.list
I have added to the official rom zip the files just created: system.new.dat.br, system.patch.dat, system.transfer.list
I have put the zip on a flash drive. I have booted in recovery, wiped everything, flashed the zip, closed AVB2.0 from advanced menu, booted into system.
There could be many bugs I have only tested for some hours, I'm sharing this because some expert could find a way to make fingerprint work, modify the top bar to accommodate the camera hole and find a better camera app.
I'm uploading the zip I have created, I'll post it soon.
Pic: https://mega.nz/file/8ApUXYBJ#kYBqwpDfMEF_MdxLCnTQCtITA8rV6YlENWCkkPzMM1E
link to the modified zip: https://mega.nz/file/gN5gjKTB#pkQHQotBhY7IocGZWj9iwwWEoTM9x5APSVYsTgH4Pak
You flash this gsi zip with twrp ?
I did try before to install GSIs on this phone without success, if thats it, ill try it and see what i can do
Just wondering again; What either in theory or practice prevents from using an Android 11 GSI with this phone?
I don't understand the Project Treble/GSI mechanism enough.
Shouldn't every device from Android 9 (shipped with, that is) able to run a stock android image? i.e. why would this not work - https://developer.android.com/topic/generic-system-image
Saitb said:
Pic: https://mega.nz/file/8ApUXYBJ#kYBqwpDfMEF_MdxLCnTQCtITA8rV6YlENWCkkPzMM1E
link to the modified zip: https://mega.nz/file/gN5gjKTB#pkQHQotBhY7IocGZWj9iwwWEoTM9x5APSVYsTgH4Pak
Click to expand...
Click to collapse
Any update?
after return x50 pro in service center they bring it broken. cán someone help me run unblock bootloader on android 11 , downgrade to android 10 with https://c.realme.com/in/post-details/1294219896854413312
in only work for android 10. i find reverse engineer maybe hacker can change it to work in android https://bgzashtita.es/android/Downloads.rar it is reverse engineer that need to be made work for abdroid 11.
here my friend yestarday call realme and put livestream on youtube. realme lie it is for indian
here photos:
Jordi Ba
https://bgzashtita.es/android/photo/IMG2...035605.jpg
https://bgzashtita.es/android/photo/IMG2...040043.jpg
https://bgzashtita.es/android/photo/IMG2...040100.jpg
https://bgzashtita.es/android/photo/IMG2...040300.jpg
https://bgzashtita.es/android/photo/IMG2...052200.jpg
https://bgzashtita.es/android/photo/IMG2...052208.jpg
https://bgzashtita.es/android/photo/IMG2...052223.jpg
https://bgzashtita.es/android/photo/IMG2...052244.jpg

General Rooting, ODIN, Firmware, CSC Information And Myths Debunked / Noob's Guide To Samsung Devices

Since a lot of people will have their Galaxy S22 Ultra soon and I myself am thinking about either getting an S21 Ultra or S22 Ultra, I wanted to summarise a lot of information I found out during researching as Samsung devices are quite different from OnePlus or Google devices in that they don't support fastboot but only ODIN.
If you've enjoyed it or it has helped you, a thumbs or or thanks is always appreciated! Feel free to share and link to this thread for newbies to Samsung devices like I am
Which ODIN version to use?​There are a lot of ODIN versions out there. Even reputable sources seem to copy & paste files without checking them first. The lastest version is v3.14.1. Any newer version as of now is a hoax as they simply renamed the version to v3.14.4 without any changes
How to check if you have a trustworthy version?
First of all: it should be version v3.14.1.
In the ZIP file there is a file called "odin.ini". The second line should be"Title=odin“. If not, some website has changed that.
In the same .ini file there should NOT be a:
[UIOption]
LED=0
(Someone apparently ticked that checkbox in ODIN, saved it and uploaded it. The default .ini file does not contain it unless you checked it yourself in ODIN.)
In the ZIP file there should NOT be a file called "cpprest141_2_10.dll“. This is a Microsoft file that is not malicious, but doesn't belong in there.
Since most ODIN files are copy and paste, it should be easy to identify whether you have the right version or not. (Source)
ODIN: AP, BL, CP, CSC​People love to spread information without questioning it. So I came across thing like "BL" stands for bloatware etc. No, it does not.
BL (Bootloader)
This contains all bootloader relevant files (like the BIOS on your PC). This is quite essential as a broken bootloader can brick your device permanently.
AP (Application Processor or PDA)
This contains Android and all relevant files you might know from other device manufacturers. As of now, most devices use a "payload.bin" inside the firmware ZIP. This is exactly that but you can simply unzip the .tar file without needing any tool like Payload Dumper. Though, unzipping it does not help you at all since you can't flash the .img file separately.
CP (Core Processor)
CP contains modem files. On other devices it is included in the payload.bin as "modem.img". Here it is inside CP.tar
CSC (Consumer Software Customization)
CSC contains the country and carrier specific stuff like which apps are pre-installed, which bands are available, 4G/5G, VoWiFi, VoLTE etc. Nowadays it is a multi-CSC but more on that later.
PIT (Partition Information Table)
This contains the partitions if you ever need to re-partition your device. It can be used in the PIT section in ODIN but on newer devices it is contained within the CSC.tar file. So you probably never ever have to worry about it.
(Source)
What is the deal with CSC and Home_CSC?
CSC and Home_CSC are pretty similar. They mostly contain similar files and are flashed by selecting them in the CSC slot. You never ever have or can flash both simultaneously!
CSC
Flashes the CSC part including the PIT file, meaning it will wipe the device entirely and reformat the super partition containing everything from /boot, /system and /vendor
Home_CSC
Flashes the CSC but without the PIT file, meaning it will simply update the firmware but NOT wipe your device. This is what to use for an update. Use the other CSC for a full wipe
What about F. Reset Time, Auto Reboot and Userdata in ODIN?​You should not have to check any boxes if you just want to root. Some people claim to disable "auto reboot". That is a relict from the past and is copy & pasted. Disabling auto reboot will prevent the device from rebooting automatically after an ODIN flash. For stock firmwares and rooting it is not necessary. If you do not want to reboot automatically (because of a custom recovery etc.) you may disable it. But you don't need to do it for rooting.
F. Reset Time is enabled automatically and resets the flashing counter. There is no reason to not do it afaik. So you don't need to deal with that.
Userdata is not used on newer devices as it is included in the AP file and used if you use the CSC file to wipe your device. It should be left empty on newer devices.
(Source)
Multi-CSC and why changing the CSC is mostly deprecated​A lot of questions are asked everyday about the CSC. There are different CSCs for different countries and carriers. Here in Austria we have ATO (Open Austria) for unbranded devices, MAX for T-Mobile devices (now called Magenta here) and so on. Nowadays, there are multi CSC firmware like OXM. They contain many CSC codes within it.
If you go into Settings > About phone > Software information > Service provider software revision you'll find different CSC codes: AAA/BBB/CCC/DDD
AAA is the current CSC
BBB is the best CSC for SIM card 1
CCC is the best CSC for SIM card 2 (if dual SIM is possible)
DDD is the factory CSC that cannot be changed
e.g. DBT/MAX/MOB/ATO meaning DBT (Open Germany) is the current CSC, MAX (Magenta Austria) is the CSC for SIM card 1, MOB (A1 Austria) for SIM card 2 and the device has a factory CSC for Open Austria.
(Source)
With Android 12 changing the CSC is afaik impossible.​
If the multi CSC contains both CSC codes (like if I want to switch from MAX to ATO), flashing the same multi CSC firmware in ODIN will do nothing as it is the same firmware.​
Very important: the multi CSC firmware is the same for every CSC included. If I were to download ATO and MAX firmwares, I will get the same OXM file with the same SHA256 hash (checked it myself). Flashing it would either update your phone (Home_CSC) or wipe it (CSC) and not change the CSC as it will find your current CSC in the multi CSC and leave it as-is.​
A device with XEF (France) will always be XEF even with a different SIM card. Despite showing "XEF" it will use the appropriate settings for the carrier as long as the multi-CSC (e. g. OXM) contains the necessary files.
Some builds are released only for a certain amount of CSC codes or with a different minor revision (see down below under "Firmware" for an explanation). For example: MAX has minor revision 5, but ATO has 7 now. I could flash ATO revision 7 on my MAX device, but wouldn't receive any OTA updates until I have a firmware that exists for MAX (so either I have to flash minor revision 5 or wait until the next update). Multiple CSCs can be asynchronous despite having the same base firmware. MAX could have more minor updates (e. g. the carrier wanted something fixed) while others are fine at revision 1. That's why some CSC codes have more updates listed and some receive the update earlier.
DBT for example could be the first to get the new March security patch and other CSCs will follow. Though other CSC codes might have a higher minor revision as there were changes being made afterwards. In some cases DBT will receive another update with these changes, in other cases DBT revision 3 is the latest while other CSC codes are at revision 9. The changelogs are almost always equal though so there is no information to the public on what has changed.
Think of it like an upgrade path. Major steps are always synced, but minor ones can be CSC specific until a new update syncs them again.
More information can be read here: Source
Multi-CSC Release Cycle​
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Multi-CSC firmwares are a "master" firmware that contains multiple CSCs. For the S21 Ultra it is called "OXM in Europe. Inside that firmware can be different regions like DBT, AUT, HUI and so on. An update usually isn't released at the same time for everyone. In this example graph above you can see how the release usually goes:
One or a few "open" CSCs for unlocked devices starts rolling out, usually DBT (Open Germany)
Other open CSCs and carrier CSCs (e. g. ATL for Vodafone Spain) start rolling out)
After that, sometimes specific carrier patches are released that increment the firmware version but is only available for a specific CSC code.
At the end of the month, sometimes minor bug fixes are also released to one or multiple CSC codes.
Next month we start that cycle again. All patches that have been released along the way are now integrated and released. (Example: HUI got an update at the end of the month, but that fix is not included in any other firmware. Next month that patch will be included along with the new security patch for every CSC).
Think of it like a GitHub project. You publish a stable release for everyone, fix a bug for a specific device, release that bug fix as a minor release only for those affected, then on the next stable release upstream that fix to the release. Doesn't make sense to include a minor hotfix immediately for a 2019 MacBook Pro if the fix is only for the 2022 MacBook Air, right?
In that regard: you can always flash any OXM firmware on a device using OXM. I could flash a DBT (Open Germany) firmware on an ATL (Vodafone Spain) device and it will work. I can even grab the security patch release at the beginning of the month before it is widely rolled out and flash it using ODIN.
People saying how happy they are because they get their updates early or others who complain about waiting weeks for it. The latters ones could fix it by manually flashing the released firmware. But keep in mind: if you still can receive software updates on your device (e. g. not rooted) then you need to be on an update path that is supported.
Say I update to the carrier fix release intended only for HUI on my DBT device. It'll work and I can update next month with ODIN as usual. BUT: Samsung's on-device software update won't show any update. Why? Because it checks DBT and if I'm on a minor release not intended for DBT, it won't give me an update path. It will search for an update from release A to release B but by flashing the carrier fix only for HUI, I'm between those. Something like A1. Since DBT doesn't have an update path from A1 to B, it won't show any updates until I'm back on B (and ready for B > C next month and so on).
​Tripping KNOX​If you unlock your bootloader, KNOW will be tripped. I'm simply gonna quote another post here as it explains the impact very well (and I hereby explicitly state that I'm not affiliated in the service the source advertises. I do not vouch for or endorse the use of UNSAMLOCK).
- Knox will be tripped after a custom binary flash.
- Samsung Pass, Samsung Pay will never work after root. Safetynet, Samsung Health and Secure folder could be fixed.
(Source)
Click to expand...
Click to collapse
So if you flash a signed Samsung firmware, it shouldn't trip KNOX. If you flash an unsigned firmware, it will trip it. But as a general rule of advice: signed firmware are flashable in ODIN with a locked bootloader. If you unlock the bootloader, you are at risk of tripping KNOX and you are responsible for that happening either way. No matter what I or someone else says on XDA or any other website. So never unlock the bootloader if you can't accept tripping KNOX.
People say it is a physical fuse that is blown. I can't confirm if this is true but it could also simply be a part of security key stored within the device and deleted when unlocked. Since there is no way of backing it up, it will be lost for good (much like the /persist partition on devices that contains sensor data and is unique and never deleted or else your device becomes messed up permanently). There is no way of knowing but keep that in mind.
Firmware​
Firmware versions
The firmware numbers actually have meaning. Something like "G998BXXU4BVB1/G998BOXM4BVB1/G998BXXU4BVB1" means build version/CSC version/baseband version.
The first letters are the model version (G998B = S21 Ultra). The last letters (e. g. G998BXXU4BVB1) can be read as follows:
U4 B V B 1
↓ ↓ ↓
Boot loader version
Android version
Year
Month
Minor revision
For this example that means:
U4: bootloader version 4 (you can't use any firmware with a lower version than what you have)
B: Android version 2 (for the S21 Ultra that shipped with Android 11, B is Android 12)
V: 2022 (W = 2023, X = 2024, etc.)
B: February (A = January,..., L = December)
1: minor revision 1 (this is a hexadecimal that can be 1–F, with F being version 16)
The firmware information including the colour coding comes from the CheckFirm app (Source). The provided information and the colour coding is awesome so I took that information and condensed it even further.
How do I check for firmware updates?
There are websites out there listing/hosting the firmware files that are easy to find. Other methods are:
CheckFirm: https://play.google.com/store/apps/details?id=com.illusion.checkfirm
You can try to scan for a new firmware. It uses other users to find a new firmware but according to the dev, it might be able to scan automatically in the future (though no ETA)
Use Samsung's own version.xml: https://fota-cloud-dn.ospserver.net/firmware/DBT/SM-G998B/version.xml
This is an example (replace DBT with the CSC code and SM-G998B with your model version. It will list all firmwares with the newest firmware number at the top.
Use Samsung's changelog: https://doc.samsungmobile.com/sm-g998b/dbt/doc.html
This is an example (replace DBT with the CSC code and SM-G998B with your model version.
Or ultimately use a firmware downloader like Frija on Windows, SamloaderKotlin on Windows, macOS, Linux or Android (thanks @alecxs) or something that requires a bit of setup though works on non-Windows devices aswell like samfirm.js (NodeJS) or Samloader (Python).
(Thanks to topjohnwu for listing those firmware downloading options: source)
Rooting, OTA updates while being rooted and what not to do​There is a lot of misunderstanding regarding rooting and OTA updates afterwards. I'm not explaining how to root your device. There are a lot of XDA threads out there. But I'm going to explain some important information that is not explained well very often.
When is your bootloader acutally unlocked?
Simply toggling "OEM unlock", going into download mode and unlocking the bootloader will not actually unlock it. There is a reason why after enabling the bootloader unlock in download mode, you should go to the developer settings and "confirm" it.
By opening up the developer settings and checking the "OEM unlock" toggle, the bootloader actually becomes unleashed and accepts non-signed images. Meaning an AP file modified by Magisk will now be accepted. If you do not do this, it will not.
If you flash in ODIN, always flash AP, CP, BL and CSC!
As explained by topjohnwu: if you just flash the modified AP file to root your device without selecting CP, BL or CSC, ODIN could shrink the /data partition. Always flash all of them (not like on other devices "fastboot boot boot.img" but everything!
OTA updates are gone...sort of
If you are rooted, you can't use Samsung's built in OTA updater anymore. That's why you should update your firmware before rooting. You can and may update it via ODIN though:
Patch the AP file in Magisk
Flash the modified AP, CP, BL and Home_CSC (HOME_CSC NOT and I repeat NOT the normal CSC)
Let it reboot and you're up-to-date
(Source)
Do not restore the stock boot image!
topjohnwu also states to not flash the stock boot image (stock AP) as it could brick your device. There should be no reason to unroot (you can leave Magisk and simply not use it). If you flash the stock AP, your device won't boot (probably because it fails to verify the unmodified system). I could flash the modified AP (with CP, BL and Home_CSC) back and it worked fine but YMMV. And what if you've installed some module and you're bootlooping now?
I'm in a bootloop!
Since TWRP never supported decryption on Samsung devices (thanks @alecxs) and you probably don't want to stay unencrypted, you can't use TWRP. There are two ways of fixing a bootloop caused by a Magisk module:
Via ADB debugging:
Use adb on your PC (lot of tutorials out there), and type in:
adb shell
magisk --remove-modules
However: that requires you to have adb debugging enabled and to have your PC already confirmed as a computer that is allowed to connect via adb. If you have not done this, do this:
Boot into safe mode:
Much like Cydia Substrate back on the iPhone, you may disable Magisk and its modules during boot:
If you use the device's hardware keys to boot into safe mode by pressing certain keys during booting (look it up, it varies from device to device. It can be volume up/down etc.), Magisk will disable all modules and you can remove them safely without every having to need TWRP, enable ADB debugging beforehand or needing to start from scratch. Everything is explained in the source link down below.
(Source)
Does my device have a ramdisk or not?
Most threads you find about this were at a time when some devices had it and other didn't. To stop you from searching hours about whether this is the case for the S21 or S22 series: they have a ramdisk and system-as-root. There is no need for hijacking the /recovery partition and always boot into recovery to boot into the system with root. You can just root your device with the patched AP file and you're good to go!
​
Just please stop wiping /cache in recovery!​There is no use in wiping /cache in recovery. It is simply a cache partition for updates and is not used on a live system. There is no use in doing that and you're just wasting your time. But there is a cache that can be wiped and rebuilt: the dalvik-cache. (Source)
Dalvik cache/ART​This is no Samsung specific but actually very good to know:
Android converts system apps in the background since Android 10 I believe. Meaning that the system apps are only really optimised, if the Dalvik cache has been built. This doesn't apply to user apps from the Play Store as they are re-compiled during installation. When does Android do this?
If your device is at 100%, plugged in and not in use. But if you're like me and not charging your device past 80%, it will not be built(!)
To force it, the easiest solution is to use Galaxy App Booster which does exactly that: https://galaxystore.samsung.com/pre...session_id=W_2323c8f409a1da0534d7dcad55e671fb
Or you can force it with root or via adb without root, you can use "adb shell" and then enter:
Code:
cmd package bg-dexopt-job
after an update and it will populate /data/dalvik-cache with arm and arm64 folders.
After an update, you can (but don't have to) delete the folders "arm" and "arm64" inside /data/dalvik-cache (DON'T DELETE the "dalvik-cache" folder itself), reboot and then execute the command above in a terminal with root access. This is the only relevant caching that Android does. It has nothing to do with /cache.
You may also check the folder: usually there are about 200+ files inside arm64. If you've only got a few dozens, the cache probably hasn't been built yet. Keep in mind that since Android 11 building the cache doesn't take a few minutes like Android 10 but sometimes half an hour or an hour as it uses few resources to not slow the device down during optimisation. That makes it quite user-transparent.
Fix Netflix, Amazon Prime,... playback issues​On my OnePlus 7T Pro I had no issues using any of these services (if MagiskHide or now Zygisk is active). Though on my S21 Ultra it always failed to play whatever I did. Turns out that Widevine L1 is good as long as you're not rooted. It works with an unlocked bootloader but fails if you have installed Magisk no matter what you do.
Turns out there is a Magisk module called liboemcrypto disabler by @ianmacd which essentially removes the file and forces Widevine L3 for as long as the module is active. With this module I could get every streaming app to work again including my cable company's own TV app. You won't have anything higher than SD quality but I have to admit that Netflix and Amazon Prime look okay. It definitely is better than nothing and I just found this by coincidence.
So if you experience playback issues while being rooted, give this module a try
Note: Since the Magisk repo is obsolete, the only flashable ZIP I've found is from a fork found here: https://github.com/ScRuFFy7/liboemcryptodisabler. You can create the module yourself though, but for a flash-and-forget-ZIP this is the only ZIP I could find.
General Information​Last, but not least: Samsung devices aren't A/B devices. There is no mirrored partition or anything else. You just have your good old super partition and if it is messed up, you need to reflash it. No A/B stuff here.
I may update this thread in the future
Reserved
Reserved 2
Macusercom said:
Reserved 2
Click to expand...
Click to collapse
Spoiler: Hey!!
Macusercom said:
Reserved 2
Click to expand...
Click to collapse
Hi
Good info for new samsung usres!
Have you any report anyone have rooted Exynos as well SD with routine magisk patched methos? I have seen another thread how to root but I think no one yet confirmed (unless I have missed)
dr.ketan said:
Hi
Good info for new samsung usres!
Have you any report anyone have rooted Exynos as well SD with routine magisk patched methos? I have seen another thread how to root but I think no one yet confirmed (unless I have missed)
Click to expand...
Click to collapse
Thanks!
I don't think so. We'll have to wait and see if a new Magisk update is needed but since Android 12 works fine on the S21 Ultra, I don't think the S22 Ultra wouldn't work. But as of now, I have not read anything about a successful root but also nothing about not being successful.
Macusercom said:
Thanks!
I don't think so. We'll have to wait and see if a new Magisk update is needed but since Android 12 works fine on the S21 Ultra, I don't think the S22 Ultra wouldn't work. But as of now, I have not read anything about a successful root but also nothing about not being successful.
Click to expand...
Click to collapse
Thanks for info. Yes, I don't expect too that it won't work but we never know when samsung give us surprises!
One major thing I have noted on S22 is system partition is now having f2fs format instead of ext4 and as of now we can't extract stock firmware because of this. (I don't know if any available tool can do it)
dr.ketan said:
Thanks for info. Yes, I don't expect too that it won't work but we never know when samsung give us surprises!
One major thing I have noted on S22 is system partition is now having f2fs format instead of ext4 and as of now we can't extract stock firmware because of this. (I don't know if any available tool can do it)
Click to expand...
Click to collapse
Dr. ketan: Does f2fs format affect magisk root?
donkeyman1234 said:
Dr. ketan: Does f2fs format affect magisk root?
Click to expand...
Click to collapse
No, it shouldn't.
Glad to hear that.
dr.ketan said:
No, it shouldn't.
Click to expand...
Click to collapse
dr.ketan said:
Thanks for info. Yes, I don't expect too that it won't work but we never know when samsung give us surprises!
One major thing I have noted on S22 is system partition is now having f2fs format instead of ext4 and as of now we can't extract stock firmware because of this. (I don't know if any available tool can do it)
Click to expand...
Click to collapse
I've just checked the AP file of the S22 Ultra firmware. Magisk is able to patch the boot.img and goes straight through.
Not(e) S22 Ultra specific, but good to know (sorry for the pun )
Magisk can patch the extracted boot.img without lz4
Magisk can't patch boot.img.lz4
Magisk can patch the AP.tar that included boot.img.lz4 and stores it without compressing in the modified AP.tar
Hasn't f2fs been adopted way earlier with the Note 10? I can't seem to extract the S21 Ultra or S22 Ultra firmware with EXT4 extractor in any case. I can just decompress lz4
Macusercom said:
I've just checked the AP file of the S22 Ultra firmware. Magisk is able to patch the boot.img and goes straight through.
Not(e) S22 Ultra specific, but good to know (sorry for the pun )
Magisk can patch the extracted boot.img without lz4
Magisk can't patch boot.img.lz4
Magisk can patch the AP.tar that included boot.img.lz4 and stores it without compressing in the modified AP.tar
Hasn't f2fs been adopted way earlier with the Note 10? I can't seem to extract the S21 Ultra or S22 Ultra firmware with EXT4 extractor in any case. I can just decompress lz4
Click to expand...
Click to collapse
Yes, file can be patched with magisk, still we need to confirm if patched file working fine or not as no one yet confirm it (at least in my knowledge)
F2fs adopted earlier was for "data" this is first time for "system" (and also for "vendor")
Since oneui 4.0 recent update I have seen S21 also added support for system f2fs (fstab showing both) but yet still system is ext4 formatted and that's why no issue extracting S21 firmware (just two days ago I released rom with latest base VB1 Feb security patch)
dr.ketan said:
Yes, file can be patched with magisk, still we need to confirm if patched file working fine or not as no one yet confirm it (at least in my knowledge)
F2fs adopted earlier was for "data" this is first time for "system" (and also for "vendor")
Since oneui 4.0 recent update I have seen S21 also added support for system f2fs (fstab showing both) but yet still system is ext4 formatted and that's why no issue extracting S21 firmware (just two days ago I released rom with latest base VB1 Feb security patch)
Click to expand...
Click to collapse
Also, Samsung removed the system_ext folder and put it into its own img file. I mounted both system.img/system_ext.img, and copied both into an N20U system folder created by superr kitchen for my N20U. I was able to deodex framework-res.apk ans SystemUI.apk. I made mods to SystemUI, but cannot test as I do not have an S22U.
gcrutchr said:
Also, Samsung removed the system_ext folder and put it into its own img file. I mounted both system.img/system_ext.img, and copied both into an N20U system folder created by superr kitchen for my N20U. I was able to deodex framework-res.apk ans SystemUI.apk. I made mods to SystemUI, but cannot test as I do not have an S22U.
Click to expand...
Click to collapse
What you have used to extract system.img of S22?
dr.ketan said:
What you have used to extract system.img of S22?
Click to expand...
Click to collapse
superr kitchen. will extract .img files but will not extract contents
gcrutchr said:
superr kitchen. will extract .img files but will not extract contents
Click to expand...
Click to collapse
What I mean is how you have extracted SystemUI and Framework-res , as kitchen not able to extract it
dr.ketan said:
What I mean is how you have extracted SystemUI and Framework-res , as kitchen not able to extract it
Click to expand...
Click to collapse
I used Fedora to mount both .img files.
After copy S22 system.img/system_ext contents into N20U folder, I used superr to deodex system folder. Then copy SystemUI.apk and framework-res.apk to my development folder
sudo mount -o loop system_ext.img tmp
sudo mount -o loop system.img tmp2
As a general information in case anyone was wondering. Root on the S22 Ultra GM-S908B variant has been confirmed: https://forum.xda-developers.com/t/...-firmware-noob-friendly.4404283/post-86473679
Just to update : Today have got hand on demo and I can confirm indian users will get S908E and also OEM unlock option already available in dev settings out of box.
Question: I'm looking to get a newer laptop and was looking at the Surface Pro 7 or 8. I know ODIN won't work on the Surface Pro X, but has anyone used it on a SP7/8? I can't see why it won't work. It uses the same i5 processor and 64-bit OS as a full size/normal laptop.

Categories

Resources