Database Develop

29/Dec r1: NoMoreNags - Patched GoogleServicesFramework to disable OTA nags

This is a patched GoogleServicesFramework.apk that removes the OTA nags if you are using an older (e.g. GRH55) build.prop on your Nexus S. Let me know how it works out for you.
To install, reboot to recovery, then:
Code:
adb shell mount /system && adb shell rm /system/app/GoogleServicesFramework.* && adb push GoogleServicesFramework.apk /system/app && adb reboot'.
Of course, doing a Nandroid backup first is a VERY good idea.
r1 - DOWNLOAD (ROMraid Load Balancing) - MD5: 53c11f9d3196c06173bfe257aeb2ee89
P

Thanks Paul. I followed the directions and used it with r2 and I'm still getting the OTA nag. Any suggestions? Thanks in advance.

I imagine you already had the update downloaded and ready to install before you installed this.
Just select 'Install', let it reboot to the triangle, then reboot by pulling the battery.
P

Stock checker zip (prepare for OTA) - Now with more Lollipop!

Here are some flashable zips I've created to check your system partition and optionally replace any files with their stock counterparts. This is particularly useful for preparing your phone for an OTA (when you get those annoying error messages that say "{APP} has unexpected contents"). You'll need to flash the zip for your specific version of Android. You can flash this as many times as you want and can flash the OTA directly after flashing this.
You need a custom recovery to flash these! For the Lollipop OTA, after flashing the correct check/fix zip, you will need to flash the stock recovery in order to install the OTA!
KTU84P to LRX21O
Just check your system files
Code:
File: system_check_hammerhead_lrx21o-from-ktu84p.zip
[url=http://goo.gl/ooEpTy]Google Drive[/url]
[url=http://goo.gl/HPxP9O]MEGA[/url]
MD5: 10e436b5d4042145b3789ee9b9fcecb5
Size: 267 kb
Check and fix your system files:
Code:
File: system_fixer_hammerhead_lrx21o-from-ktu84p.zip
[url=http://goo.gl/mFfusU]Google Drive[/url]
[URL=http://goo.gl/VA9tuo]MEGA[/URL]
MD5: 2ae0f21d76429538f4ae854da67f5857
Size: 153 mb
KTU84M to KTU84P
Just check your system files:
Code:
File: system_check_hammerhead_ktu84m.zip
[url=http://goo.gl/ESNUH0]Google Drive[/url]
[url=http://goo.gl/fYKyvn]MEGA[/url]
MD5: 79b54a842debb992d0ef03eb2d7bc661
Size: 192 kb
Check and fix your system files:
Code:
File: system_fixer_hammerhead_ktu84m.zip
[url=http://goo.gl/sZsjz4]Google Drive[/url]
[url=http://goo.gl/1z732L]MEGA[/url]
MD5: a80331b5406042e2212fa0fe3bfeaa30
Size: 244 mb
KOT49H to KTU84M
Code:
File: check_hammerhead_kot49h_system.zip
[url=http://goo.gl/xLlREk]Google Drive[/url]
[url=http://goo.gl/lNRLlk]MEGA[/url]
MD5: 3a810e0d67e2f7b17af947a9c46664ec
Size: 402 MB
If you want to check the updater-script that is in the zip file without downloading the whole thing, [url=http://pastebin.com/kUAimyYK]I've made a paste for easy access.[/url]
Standard disclaimer: I am not to be held responsible if this messes up your phone in any way. Make sure you have backed up your phone and have backups of your backups. I created it for myself and figured I'd share what I created to benefit others. Just because it works for me does not mean it will work for you. If an alien pops out of your phone or it suddenly implodes or you lose everything on it and have no backups is not my problem.
For those of you who are interested in how I generated this, you'll find the script I created to generate the file below.
System checker script (not for the faint of heart!):
If you want to run this to create the zip file yourself, you'll need a zip file of the system directory for the version you're upgrading from and the OTA zip. I'm sure there's a better way to do all this, but this is what my convoluted mind gave me...
Call the script as (2nd argument is optional) ${0} OTA.zip [system_files.zip]
Code:
#!/bin/bash
# This requires 1 argument: the update zip filename
# Also accepts 1 optional argument: system files zip filesname
update_zip=$1
if [ -z ${update_zip} ]; then
echo "Need to let me know the name of the ota zip file!"
exit 1
fi
extract_dir=/tmp/update_zip_check
update_dir="META-INF/com/google/android"
eval $(echo ${update_zip} | sed 's!\([^\.]*\)\.signed-\([^-]*\)-\([^-]*\)-from-\([^\.]*\).*!update_hash=\1\nhw_name=\2\nnew_ver=$(echo \3 | tr [A-Z] [a-z])\ncurr_ver=$(echo \4 | tr [A-Z] [a-z])!')
system_zip=${2:-$(ls system*${hw_name}*${curr_ver}.zip)}
fixer_zip="system_fixer_${hw_name}_${new_ver}-from-${curr_ver}.zip"
check_zip="system_check_${hw_name}_${new_ver}-from-${curr_ver}.zip"
echo -e "\n\n${update_hash}\n${hw_name}\n${new_ver}\n${curr_ver}\n${system_zip}\n${check_zip}"
sha1sum -c <<EOF
${update_hash} ${update_zip}
EOF
if [ $? != 0 ]; then
echo "${update_zip} doesn't match hash; please re-download"
exit 255
fi
[ -d "${extract_dir}" ] && rm -rf "${extract_dir}"
mkdir "${extract_dir}"
echo "Updating updater-script for checking and replacing files."
unzip -q -d "${extract_dir}" "${update_zip}" "${update_dir}/update-binary" "${update_dir}/updater-script"
# The following was the old way of updating files
#unzip -q "${system_zip}" $(grep -e 'mount' -e 'getprop' -e 'assert(apply_patch_check(' -e 'assert(apply_patch_space(' ${extract_dir}/${update_dir}/updater-script | sed 's|^assert(\(apply_patch_check("/\)\([^"]*\)\(.*")\));|ifelse(\1\2\3, "", (package_extract_file("\2", "/\2"); ui_print("\/\2")));|' | tee -i ${extract_dir}/${update_dir}/updater-script_check | grep -e 'ifelse' | sed 's|^ifelse(apply_patch_check("/system/\([^"]*\)".*|\1|') -d ${extract_dir}
unzip -q -d "${extract_dir}" "${system_zip}" $(grep -e 'mount' -e 'getprop' -e '^apply_patch_check(' -e '^apply_patch_space(' ${extract_dir}/${update_dir}/updater-script | sed 's!^\(apply_patch_.*\) || abort("\\"/system/\(.*\)\\" .*);$!\1 || (ui_print("Need to fix /system/\2"); package_extract_file("\2", "/system/\2"));!' | sed 's!^\(apply_patch_check.*\) || abort("\\"\(EMMC:/dev/block/platform/.*/by-name/boot\).*);$!\1 || (ui_print("Flash boot partition"); package_extract_file("boot.img", "\2"));!' | sed 's!abort!ui_print!' | tee -i ${extract_dir}/${update_dir}/updater-script_fixer | grep -e '^apply_patch_check("/' | sed 's!^apply_patch_check("/system/\([^"]*\)".*!\1!')
sed 's!; package_extract_file([^)]*)!!' ${extract_dir}/${update_dir}/updater-script_fixer >${extract_dir}/${update_dir}/updater-script_check
mv "${extract_dir}/${update_dir}/updater-script_fixer" "${extract_dir}/${update_dir}/updater-script"
cur_dir="$(/bin/pwd)"
cd "${extract_dir}"
echo "Now creating the zip file for flashing."
zip -qr "${cur_dir}/${fixer_zip}" *
mv "${extract_dir}/${update_dir}/updater-script_check" "${extract_dir}/${update_dir}/updater-script"
zip -qr "${cur_dir}/${check_zip}" META-INF
cd "${cur_dir}"
rm -rf "${extract_dir}"
echo 'Done! Please remember to backup any APKs you have replaced on the /system partition of your device; this file will replace with the stock version for your build.'

Clever and people will find this usefull.
Thanks

Very Nice, Thanks
You could also include checks for other partitions (boot, recovery...)

no fix option for KTU84P? or am I blind, cheers for the zips though

pedja1 said:
Very Nice, Thanks
You could also include checks for other partitions (boot, recovery...)
Click to expand...
Click to collapse
In the OTA checks and fixes, the zip checks everything the OTA does, which usually includes free space, modem, and kernel. The zip will alert you to these and, in the case of boot/kernel, it will install the stock kernel. You're on your own for the modem, though.
Natherul said:
no fix option for KTU84P? or am I blind, cheers for the zips though
Click to expand...
Click to collapse
Right now, that file would be HUGE since it would include every file in the system partition. I was planning on waiting for the OTA to drop to make one, but... Give me half an hour and I'll cook something up for you
Edit: I have added a new file that checks and fixes all KTU84P system files.

I have uploaded the new zips for the released OTA! Get them now!
KTU84P to LRX21O
Just check your system files
Code:
File: system_check_hammerhead_lrx21o-from-ktu84p.zip
[url=http://goo.gl/ooEpTy]Google Drive[/url]
[url=http://goo.gl/HPxP9O]MEGA[/url]
MD5: 10e436b5d4042145b3789ee9b9fcecb5
Size: 267 kb
Check and fix your system files:
Code:
File: system_fixer_hammerhead_lrx21o-from-ktu84p.zip
[url=http://goo.gl/mFfusU]Google Drive[/url]
[URL=http://goo.gl/VA9tuo]MEGA[/URL]
MD5: 2ae0f21d76429538f4ae854da67f5857
Size: 153 mb

I'm slightly confused by the red labels. I have version KTU84P and want to return it to stock so I can update using the OTA (when it's available). Which file should I download to ensure my files are stock again? (I would assume the files named KTU84P to Lxxxx would be the ones?)
Also, will this remove root at all so I would be able to simply download and install the OTA?

danaconda1 said:
I'm slightly confused by the red labels. I have version KTU84P and want to return it to stock so I can update using the OTA (when it's available). Which file should I download to ensure my files are stock again? (I would assume the files named KTU84P to Lxxxx would be the ones?)
Also, will this remove root at all so I would be able to simply download and install the OTA?
Click to expand...
Click to collapse
Yes, use the KTU84P to LRX21O to check/fix your KTU84P version. This will not remove root, it just checks the APKs and files that the OTA checks to make sure they're at the right version for patching.

crazycaveman said:
Yes, use the KTU84P to LRX21O to check/fix your KTU84P version. This will not remove root, it just checks the APKs and files that the OTA checks to make sure they're at the right version for patching.
Click to expand...
Click to collapse
Hi how to run that script on Windows?
Im trying to run adb sideload system_fixer_hammerhead_lrx21o-from-ktu84p.zip and Im getting error:
Veryfing update package....
E: footer is wrong
E: signature veryfication failed
Instalation aborted.
Any ideas?
Thanks,
K.

Please help me how to apply fix script.
Thanks,
K.

ikavior said:
Hi how to run that script on Windows?
Im trying to run adb sideload system_fixer_hammerhead_lrx21o-from-ktu84p.zip and Im getting error:
Veryfing update package....
E: footer is wrong
E: signature veryfication failed
Instalation aborted.
Any ideas?
Thanks,
K.
Click to expand...
Click to collapse
Sounds like you have stock recovery; these zip files are like custom ROMs and need a custom recovery (e.g. ClockworkMod, TWRP)

crazycaveman said:
Sounds like you have stock recovery; these zip files are like custom ROMs and need a custom recovery (e.g. ClockworkMod, TWRP)
Click to expand...
Click to collapse
So I cant fix thish without wipe my data ?

ikavior said:
So I cant fix thish without wipe my data ?
Click to expand...
Click to collapse
If your bootloader is locked, that is correct. However, if you are getting an "unexpected contents" error when flashing the OTA and are rooted, you can extract this zip file and replace the file(s) manually with the stock version.

ikavior said:
So I cant fix thish without wipe my data ?
Click to expand...
Click to collapse
Actually, on 4.4 you could root with Towelroot and unlock ur bootloader without wiping.

Script error
So I am getting an error that the script (and the OTA.zip) says the script expects that my device should have 4.4.4/KTU84P/1227136 or 5.0/LRX21O/1570415 release keys but my device has 4.4/KRT16M/893803 release keys. However when looking at device status my device says the following:
-Device Version 4.4.4
-Baseband Version M897A-2.0.50.1.16
-Kernel Version 3.4.0-gd59db4e [email protected] #1
-Build Number KTU84P

I'm in the same situation, the checker and supposed fixer both produce the same message as above. I tried un-rooting and reflashing both zips (I'm on stock recovery but using fastboot to boot into CWM - efrant's old way for the Galaxy Nexus, worked with SuperSu so far) but the message persists.

pauleyc said:
I'm in the same situation, the checker and supposed fixer both produce the same message as above. I tried un-rooting and reflashing both zips (I'm on stock recovery but using fastboot to boot into CWM - efrant's old way for the Galaxy Nexus, worked with SuperSu so far) but the message persists.
Click to expand...
Click to collapse
Instead of using CWM to flash the OTA update, try sideloading the update using the stock recovery. Something has changed with the lollipop update, and it doesn't seem like TWRP or CWM can flash it (at least I haven't been able to do it).
Sent from my Nexus 5 using Tapatalk

Remind me where I can get the stock recovery?
Sent from my Nexus 5 using XDA Free mobile app

efrant said:
Instead of using CWM to flash the OTA update, try sideloading the update using the stock recovery. Something has changed with the lollipop update, and it doesn't seem like TWRP or CWM can flash it (at least I haven't been able to do it).
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
To be honest, "nothing" changed, only that now it reads kitkat's kernel properties instead of the build.prop file directly. As I posted in the help-desk:
RusherDude said:
The fun part is that this is a bug that I saw loong ago coming.. I don't why recoveries can't STILL access android kitkat kernel properties, but they work ok reading the file, so the OTA 4.4.4 worked fine, that tries:
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/hammerhead/hammerhead:4.4.3/KTU84M/1158763:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/hammerhead/hammerhead:4.4.4/KTU84P/1227136:user/release-keys" ||
abort("Package expects build fingerprint of google/hammerhead/hammerhead:4.4.3/KTU84M/1158763:user/release-keys or google/hammerhead/hammerhead:4.4.4/KTU84P/1227136:user/release-keys; this device has " + getprop("ro.build.fingerprint") + ".");
Which works OK, tho if you notice the error case, the description would fail because it uses getprop...
NOW on 5.0 they use the same getprop for both cases, and fail:
getprop("ro.build.fingerprint") == "google/hammerhead/hammerhead:4.4.4/KTU84P/1227136:user/release-keys" ||
getprop("ro.build.fingerprint") == "google/hammerhead/hammerhead:5.0/LRX21O/1570415:user/release-keys" ||
abort("Package expects build fingerprint of google/hammerhead/hammerhead:4.4.4/KTU84P/1227136:user/release-keys or google/hammerhead/hammerhead:5.0/LRX21O/1570415:user/release-keys; this device has " + getprop("ro.build.fingerprint") + ".");
So modifying the update scripts its a simple solutions (tho It changes the file signature and so, and it's official OTA so no way..).
Click to expand...
Click to collapse
This is a custom recoveries bug from 2013 when Kit Kat came out, still unsolved and if they don't do something we will need to flash stock recovery and stuff every OTA from now on.

I didn't understand - does the fixer flashes a new recovery? (currently can't download the zip file to check if there is any recovery img inside.. )

*Working Great[Flyme 7 Erfan GSIs Global] [Android 9][Thanks Vega]

Special thanks to Vega from O grupo de discussões sobre tecnologia e outras coisas!
Information:
Android Version: 9
Brand: meizu
Model: meizu note9
Codename: meizunote9
Build Type: K81923AA1-user
Build Number: PKQ1.181203.001
Incremental: 1552448469
Tags: release-keys
Security Patch: 2019-02-01
Fingerprint: meizu/meizu_note9/meizunote9:9/PKQ1.181203.001/1552448469:user/release-keys
Description: meizu_note9-user 9 PKQ1.181203.001 1552448469 release-keys
Raw Image Size: 2.40 GiB
==============================
Downloads: ARM64 Aonly (https://drive.google.com/file/d/1kc2sDvAh1TX-HWem2Hp5eLKNp-JIqgLC/view?usp=sharing)
===============================
Bug: from my vendor ====NO SIM DETECTED====
==================================
Not Support: exFAT
Step
1. flash latest Firmware https://mega.nz/#!QDplSYab!mrB5f8875VghQHfrrGvid4iJICMopkq3anZCipLWzqo
2. flash Vendor https://mega.nz/#!ECAG1aIS!OuGf9eVoiJpg0xreeLIarAWs5GkuCbu9AwR95MSlO-g
3. flash GSI as System Image
4. flash Permissiver v4.zip https://mega.nz/#!ETIwHQJC!Go5NfpgXFy5gPw8gFG8JbUCch7Eijw4rDp3NVTkhd-M
5. flash Disable_Dm-Verity_ForceEncrypt_10.20.2019.zip https://mega.nz/#!gTohmQaR!ZL5jCeatYXUzUMx_moJseJ9o7b1RoLUf3o_PfOtn_aw
6. flash DisableForceEncryption_Treble_v20.1.zip https://mega.nz/#!BHgRWYDS!jfuIRqTPTjS_lVy2tfpSbVRfqmxqqadeLFttgbKmhYQ
7.Reboot
First Boot
-System is upgrading.
-update GMS https://www.apkmirror.com/apk/googl...0400-282600551-android-apk-download/download/
-------------------------------------
-Edit /system/build.prop ( for Fixing Enable Bluetooth audio media )
enter inside twrp, mount system (and unmark option "mount system as read only"), go to advanced, terminal and write:
echo "persist.vendor.btstack.a2dp_offload_cap=false" >> /system/build.prop
echo "persist.vendor.btstack.enable.splita2dp=false" >> /system/build.prop

Oneplus 7 pro firmware collection

Ah yes, Oneplus released that new update. Now I must download 2+ GB off my capped data plan, then flash it to recovery, carefully switch back my slot then flash my custom ROM again to the slot I just flashed OOS to and then flash OOS again to the other slot and then I must repeat everything above. After that I must delete the 2 fake partitions the updater created on data because they are useless. Oh wait it doesn't let me delete them who'd have thought?
Seriously? What on earth happened there
A better solution is required, especially something that grants more control. Well here it is
The boring stuff:
I am not responsible for anything you do to your device
These zips contain the following files:
Code:
The firmware (duh)
flashall - flashes both a and b
flash_a - only flashes slot a
flash_b - only flashes slot b
The following partitions found in the official oxygenos zip have been removed:
Code:
vbmeta
boot
dtbo
odm
system
vendor
reserve
india
Because for custom ROM users these partitions are either unused or used by the currently running custom ROM
How to flash?
From TWRP (it doesn't even need to support decryption):
Code:
adb push abl.img aop.img bluetooth.img cmnlib64.img cmnlib.img devcfg.img dsp.img flash_a flashall flash_b hyp.img keymaster.img LOGO.img modem.img oem_stanvbk.img qupfw.img storsec.img tz.img xbl_config.img xbl.img /tmp/
adb shell
cd /tmp
chmod 777 flashall # or flash_a/b
./flashall # or sh flashall or use flash_a/b
I suggest you use one of the flash_a/b scripts to only flash your current slot and test the changes out before running flashall
From termux:
You might need to set selinux to permissive while flashing. Only try to flash your current slot, reboot and if there are no errors flash the other slot
unzip the zip file to a directory and cd to it. If you use termux you should already know this
Just run one of the flashing scripts as root
Note that the flashing takes some time. Do not abort it
From adb root:
Sadly I don't have adb root so if someone has it they can let me know how it goes and how they flashed it
Do NOT believe in myths. You do NOT need to wipe cache/dalvik/any other nonsense while upgrading firmware. Stop wasting your time
Downloads:
Open beta 9: https://glassrom.pw/guacamole-ob9fw.zip
More will be added when I have time
Yes I personally tested this on my device and it was fine. Except that the popup camera pops out sometimes but I just suspect big brother. Nothing abnormal
Happy flashing. Or whatever

Anybody caught the latest OOS release link yet? All I found was an incremental OTA

Is this project discontinued? If yes, I'd like to see a revival of this.

hellcat50 said:
Is this project discontinued? If yes, I'd like to see a revival of this.
Click to expand...
Click to collapse
He doesn't care about support

The link is dead.
Does anyone have this zip?
I need these files
flashall
flash_a
flash_b
in order to make an up to date zip.

alessio89g said:
The link is dead.
Does anyone have this zip?
I need these files
flashall
flash_a
flash_b
in order to make an up to date zip.
Click to expand...
Click to collapse
you can get the file list and the firmware collection from the glassrom device tree
i stopped maintaining this as now i just ship firmware into my roms
Bitbucket
bitbucket.org

flash_a, flash_b and flashall really were just script generated scripts
something like
```
for i in $(ls *img | sed 's/.img$//g')
do
echo dd if="$i".img of=/dev/block/bootdevice/by-name/"$i"_a;
done
```
same for slot b:
```
for i in $(ls *img | sed 's/.img$//g')
do
echo dd if="$i".img of=/dev/block/bootdevice/by-name/"$i"_b;
done
```
concetenate flash_a and flash_b as follows:
```
cat flash_a flash_b > flashall
```
PS: you need to remove the oem_stanvbk_{a,b} entries as that is not an A/B partition. also i have just shown you roughly what i use to generate the flash scripts. there is no guarantee these work. example you might need to remove the $ from the regex

[GUIDE] Extracting the latest OnePlus 6T firmwares from ROM update package

* Pre-note: Extracting firmwares and subsequently updating your phone's firmware by flashing the extracted firmwares, is a 2-part process. This guide is only about extracting them, and i also made another guide that is for flashing them afterwards: see [GUIDE] Flashing the latest firmware updates to your OnePlus 6T. The guides supplement eachother, depending on your needs.
General word about firmware updates:
A lot of people know of the importance and benefits of keeping your device firmware updated, just like you keep your custom ROM updated. If you don't keep them updated, you might not get the best out of your custom ROM (like: more bugs, system stability and performance problems/less speed.. also, vendor components, e.g Qualcomm and other chips, have security patches in the firmware.. "Vendor patch level" vs Android "Security patch level").
Besides incremental firmware updates from each OxygenOS release with a small changelog, too many people are missing out on huge jumps such as that they are running an Android 11 custom ROM, while their firmware was never updated so it remained a firmware originally shipped with an Android 10 (or earlier) OxygenOS release. Staying behind on huge jumps like these, cause the biggest list of problems with stability and performance. Therefore it is advisable to keep your firmware updated, and note that even small incremental updates (based on the same Android version) tend to give performance, security and stability benefits.
Let's continue.
If you can't find someone that posted the firmwares separately (or you don't trust their completeness, integrity & authencity.. it's always a potential risk) this guide will help you do it all by yourself, to extract firmwares from the original ROM update package.
GUIDE STARTS BELOW THIS LINE
Prerequisites
First step: Get the updated OxygenOS ROM, it's a zip file named in a format like this: OnePlus6TOxygen_34.J.62_OTA_0620_all_2111252336_339a2fa8335f21.zip (this happens to be the latest version as of writing, it will be outdated from now on)
Make sure to get it from an official source, i dont know where OnePlus shares direct links but i know that their practises regarding it are inconsistent (sometimes they provide, other times they don't). So i advise you to use an useful app in the Play store called Oxygen Updater that fetches it directly from OnePlus servers.
For this app.. if you're on LineageOS, you can click through to download the ROM update file but only after ignoring all warning dialogs saying things like "Unsupported device" and about root + enabling Advanced mode slider in the app's settings. So basically, these steps override 1) that you're on LineageOS (so it thinks it's unsupported) and 2) that it doesn't recognize your current version and thus doesn't offer a direct download of the file, regardless of what it fails to detect about your phone or OS, to your phone storage.. that's what Advanced mode takes care of. So after enabling Advanced mode, download the ROM .zip from the update screen in the app, and it will be placed in your phone's storage root folder
So now that you have the ROM, let's start the firmware extracting process -
Required tool: payload-dumper-go > choose latest version and download the Windows package
1) Extract payload-dumper-go to your folder "FW update"
2) Move the ROM .zip file (downloaded from Oxygen Updater app) from your phone storage to your PC, and place it in that "FW update" folder
3) Open the ROM .zip file with an archiving program, like 7-Zip
4) Extract payload.bin from within the ROM .zip file using 7-Zip, this .bin file should display in 7-Zip as shown below:
{
"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"
}
So after extracting this from the ROM .zip, you open up cmd (command prompt of Windows) and write cd [folder "FW update" location) or even better, copy cmd.exe from System32 to your "FW update" folder. I always use that method for all my maintenance, e.g it's copied to my "adb" folder as well for easy folder targeting
4) Now in cmd, use payload-dumper-go to pull firmwares from payload.bin:
Code:
Enter each command separately, after the other completes
payload-dumper-go -p abl payload.bin
payload-dumper-go -p aop payload.bin
payload-dumper-go -p bluetooth payload.bin
payload-dumper-go -p cmnlib payload.bin
payload-dumper-go -p cmnlib64 payload.bin
payload-dumper-go -p devcfg payload.bin
payload-dumper-go -p dsp payload.bin
payload-dumper-go -p fw_4j1ed payload.bin
payload-dumper-go -p fw_4u1ea payload.bin
payload-dumper-go -p hyp payload.bin
payload-dumper-go -p keymaster payload.bin
payload-dumper-go -p LOGO payload.bin
payload-dumper-go -p modem payload.bin
payload-dumper-go -p oem_stanvbk payload.bin
payload-dumper-go -p qupfw payload.bin
payload-dumper-go -p storsec payload.bin
payload-dumper-go -p tz payload.bin
payload-dumper-go -p vendor payload.bin
payload-dumper-go -p xbl_config payload.bin
payload-dumper-go -p xbl payload.bin
Now they are pulled, but will be automatically put in folder names (as subfolders to your "FW update" folder) that look like this: "extracted_20211216_135146" with unique number each. These folders contain just 1 pulled firmware (.img files) individually
Now you have to move all .img files from each of such folders, to your main directory ("FW update"). I prefer to do it like this: Windows Explorer search for *.img like below image
Select all matching results from this search and copy them to "FW update" or put them in a new subfolder "Pulled firmwares"
Now the firmware extracting process is complete. From this point, the flashing process should be picked up. I made another guide for the flashing process, if you're interested beyond the scope of this one (the act of extracting firmwares alone): [GUIDE] Flashing the latest firmware updates to your OnePlus 6T
Note on this guide: it's possible that these instructions are universal to many, if not all, other modern OnePlus devices.. or even other smartphone brands. But since i am only the owner of an OnePlus 6T, i cannot verify or test it, and therefore this guide targets the 6T. But of course, if you got some know-how you can attempt to use this guide for other models.. although you will surely have to dump the content table listing of the update's payload.bin (with this command: payload-dumper-go -list payload.bin ), to figure out which .img files to extract.. as the relevant firmware packages & components will differ per model