{
"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"
}
This is the support thread of PixelFlasher
(PixelFlasher is an open-source self contained GUI tool to facilitate Pixel phone device flashing/rooting/updating with extra features).
Note: This thread is meant for issues and problems faced in Google Pixel 7a devices, generic issues that are device agnostic should be discussed in the main thread.
For full details on where to download / usage and feature set of the tool, visit the main thread at XDA or the project's Github page.
Troubleshooting:
If you need support or assistance, the best way to get is by generating a support file from within PixelFlasher.
You can hit that big Support button on the main screen, or select it from the Help menu.
The generated support.zip file is sanitized (redacted) to keep your sensitive information (username device id ...) private.
New Release:
May 19, 2023 v5.0.0.1 release
#75 Bug fix, when device is in bootloader, type error.
#74 Added Support for Pixel 7a (lynx)
Configuration option to define the file manager to use on Linux (default: Nautilus)
Configuration option to define the terminal emulator to use on Linux (default: gnome-terminal).
Support for additional types of Factory / ROM files.
Checksum validation of firmware / ROM files (if part of the checksum is in the name, otherwise just display)
New advanced option, ability to choose the patching method (with recommendations).
Added Recovery Image patching option.
Advanced option to enable the use of busybox shell (default off).
Auto detect firmware / rom with init_boot and use init_boot for creating patches, this way future firmware don't have to be manually added to PixelFlasher.
Auto detect devices with init_boot and use init_boot for flashing, this way future devices don't have to be manually added to PixelFlasher.
Auto-popup the detected devices dropdown after a scan, to make it obvious to select that next. (Thanks @pndwal for the idea)
Show SHA-256 of adb and fastboot binaries, as Google keeps on messing up Android Platform-tools, it's necessary to whitelist / blacklist specific binaries.
#66, when checking the patched files internal SHA1, provide a confidence rating.
Check, valdiate and warn if necessary when flashing an image patched with Magisk Zygote64_32, as there are wipe implications, provide links to documentation.
Added fastbootd testing to Dry Run.
Added Github actions to build all the targets on Github.
Code refactoring, bug fixes and improvements
New Release:
May 25, 2023 v5.1.0.0 release
Support for Android platform tools version 34.0.3, and automatic setting of ANDROID_PRODUCT_OUT environment to workaround a regression introduced in version 34.0.3
Temp workaround to avoid selecting root method patching when Magisk Delta is detected.
Nicer looking / clearer manual patching dialog.
When a Pixel device is selected, PixelFlasher now displays additional information about the device's support.
Things like: Device name, version end date, security update end date, Android version, name, codename, release date, end date.
Boot image list box now displays the applied PixelFlasher patch method.
Auto-resize boot image list box columns for better readability.
Precautionary cleanup up of leftover files on the phone in case root detection software keys on presence of such files.
#77 added attrict3 to requirements.txt in case it helps with certain builds (it shouldn't be needed).
Bug fixes and improvements.
Update:
Patch Release:
v5.1.0.1 release
Exception handling when device is not in the listed Pixel devices.
v5.1.0.2 release
Skip testing fastbootd in dry run mode if Android platform tools version is > 34, is it no longer supports fastbootd (at least 34.0.3 does not)
Thank you so much for this awesome software! When trying to trying to patch the int.boot from the factory image I run into the following error "Detected Unsupported firmware, with payload.bin". Is this truly unsupported or am I doing something wrong?
I also tried extracting the payload.bin to manually pull out int.boot and patch it, which I think worked, but in the console field said something about a low confidence match and aborted the flash.
Any help would be greatly appreciated.
I downloaded the following build from google: lynx-ota-tq2b.230505.005.a1-766dbd16
Using: platform-tools_r34.0.3-windows
Pixel Flasher: v5.1.0.2 release
Gp3322 said:
Thank you so much for this awesome software! When trying to trying to patch the int.boot from the factory image I run into the following error "Detected Unsupported firmware, with payload.bin". Is this truly unsupported or am I doing something wrong?
I also tried extracting the payload.bin to manually pull out int.boot and patch it, which I think worked, but in the console field said something about a low confidence match and aborted the flash.
Any help would be greatly appreciated.
I downloaded the following build from google: lynx-ota-tq2b.230505.005.a1-766dbd16
Using: platform-tools_r34.0.3-windows
Pixel Flasher: v5.1.0.2 release
Click to expand...
Click to collapse
You are selecting an OTA image instead of firmware image.
If you click on that green button on the left of firmware selection, it should open a download link for your device, download that and process that.
Manually extracting init_boot from payload.bin is ok for patching, which you did the first time around, and it create a proper patch.
But then you proceeded to trying to patch the patched file, why would you do that?
That's when PF aborted with low confidence level.
You are 100% correct! I was using the OTA instead of the full image. Once I found the correct file, everything fell into place.
New Release:
June 01, 2023 v5.2.0.0 release
Update build workflows
Add payload_dumper functionality to PixelFlasher to handle OTA files, thanks to vm03 for sharing source code.
Added rules engine code to better / easier management of the UI widgets enabling / disabling.
Auto detect Pixel OTA image and extract boot / init_boot / vbmeta for patching and flashing.
Add Full OTA mode, which flashes full OTA image, while optionally retaining root, and best of all, for A/B devices, both slots are bootable, you can even have one rooted and one not.
Bug Fix Release:
June 01, 2023 v5.2.0.1 release
Bug fix #78 Error when opening a shell console on Linux / Mac
Update:
June 03, 2003 v5.2.0.2 release
#76 Get a better build with Github action to support more Linux based platforms (no functionality changes).
New Release:
June 06, 2003 v5.3.0.0 release
Added Github Action build on Windows 2019 with Python 3.8 to support Windows 7.
PixelFlasher now supports loading and processing Samsung Firmware (at least my Samsung's ), it would extract AP, BL, CSC, Home_CSC ... and then extract boot.img.lz4 from AP and unpack the lz4.
When creating a patch from the set boot.img, PixelFlasher will also create boot.tar to be flashed as AP to retain root.
If there was a way to pre-load odin with the extracted files, flashing could also be automated.
I know, what does PixelFlasher have anything to do with Samsung firmware? I added it for my own use.
New Release:
June 16, 2003 v5.3.1.2 release
Set Active slot now automatically reboots to system after setting the slot, unless "No Reboot" option is selected.
Update Ubuntu 20.04 build to be aligned to the same methods that Ubuntu 22.04 build uses.
Improve confidence value calculation when comparing compressed sha1 against normal sha1 to account for shift.
Do not abort when the sha1 comparison confidence value is low, leave the choice to the user.
Update Windows builds (both) as wxPython wheel path changed, rely on a more persistent URL instead.
Thank you. Work like a champ.
tim1aust said:
2 questions in re. PixelFlasher and P7a.. a) is P7a supported yet? (seems like yes) b) is PixelFlasher from AUR for Manjaro *at the same build level* (it has 5.3.1.2 in lower left)as the one from Github, et.al?
I figured it would be easier to just have a supported AUR package, so I installed that. But when I tried to use it for P7a with latest Full image, it couldn't patch the file (said it couldn't find boot.img). Of course, for P7 & P7a, it should firstly be looking for init_boot.img. Could it be due to the fact that this was a new phone which didn't yet have Magisk installed? (I guess that's 3 questions Anyway, I wound up gettng Magisk installed from scratch, so my P7a now has it installed. I'm hoping to use PixelFlasher from AUR next time.
TIA,
Tim
Click to expand...
Click to collapse
Original Post:
@tim1aust
I'm answering you in here to keep the Magisk thread clean of PF specific discussions.
Yes, PF supports Pixel 7a (lynx)
If you provide a support file, I could check what might have happened.
Thanks for answering, and pointing me to correct thread.
Unfortunately, I don't have a support file, unless the tool automatically saved one and I wasn't paying attention.
tim1aust said:
Thanks for answering, and pointing me to correct thread.
Unfortunately, I don't have a support file, unless the tool automatically saved one and I wasn't paying attention.
Click to expand...
Click to collapse
Yes, the tool creates logs, and when you click on the support button, it processes them and redacts sensitive information and creates a zip file for upload.
All you have to do is launch PF, and hit the button and share the file.
Great, attaching it here. Thanks for your help!
tim1aust said:
Great, attaching it here. Thanks for your help!
Click to expand...
Click to collapse
Thanks
Sorry I'm confused, you reported an issue with Pixel 7a (Lynx), but all I see is logs regarding Pixel 7 (Panther).
You mentioned about failed patching.
But I see nothing wrong with patching.
Code:
Creating a patch ...
Cleaning up...
- Unpacking boot image
Parsing boot image: [/sdcard/Download/init_boot_bea42eca.img]
HEADER_VER [4]
KERNEL_SZ [0]
RAMDISK_SZ [2068178]
PAGESIZE [4096]
CMDLINE []
RAMDISK_FMT [lz4_legacy]
VBMETA
- Checking ramdisk status
Loading cpio: [ramdisk.cpio]
- Stock boot image detected
- Patching ramdisk
- Pre-init storage partition device ID: REDACTED
Loading cpio: [ramdisk.cpio]
Add entry [init] (0750)
Create directory [overlay.d] (0750)
Create directory [overlay.d/sbin] (0750)
Add entry [overlay.d/sbin/magisk64.xz] (0644)
Add entry [overlay.d/sbin/stub.xz] (0644)
Patch with flag KEEPVERITY=[true] KEEPFORCEENCRYPT=[true]
Loading cpio: [ramdisk.cpio.orig]
Backup mismatch entry: [init] -> [.backup/init]
Record new entry: [overlay.d] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/magisk64.xz] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/stub.xz] -> [.backup/.rmlist]
Create directory [.backup] (0000)
Add entry [.backup/.magisk] (0000)
Dump cpio: [ramdisk.cpio]
- Repacking boot image
Parsing boot image: [/sdcard/Download/init_boot_bea42eca.img]
HEADER_VER [4]
KERNEL_SZ [0]
RAMDISK_SZ [2068178]
PAGESIZE [4096]
CMDLINE []
RAMDISK_FMT [lz4_legacy]
VBMETA
Repack to boot image: [new-boot.img]
HEADER_VER [4]
KERNEL_SZ [0]
RAMDISK_SZ [2528130]
PAGESIZE [4096]
CMDLINE []
PATCH_SHA1: 081f1391
PATCH_FILENAME: magisk_patched_26100_bea42eca_081f1391.img
Cleaning up ...
Checking patch log: /data/local/tmp/pf_patch.log ...
Getting file content of /data/local/tmp/pf_patch.log on the device ...
Return Code: 0
Deleting /data/local/tmp/pf_patch.log from the device ...
Return Code: 0
Looking for magisk_patched_26100_bea42eca_081f1391.img in /storage/emulated/0/Download ...
Checking for /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img on the device ...
File: /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img is found on the device.
Pulling /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img from the phone to: magisk_patched_26100_bea42eca_081f1391.img ...
Pulling remote file: /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img from the device to: "/home/REDACTED/.local/share/PixelFlasher/tmp/magisk_patched_26100_bea42eca_081f1391.img" ...
Return Code: 0
Getting SHA1 of /home/REDACTED/.local/share/PixelFlasher/tmp/magisk_patched_26100_bea42eca_081f1391.img ...
SHA1 of magisk_patched_26100_bea42eca_081f1391.img file: 081f1391b700afb8ef5b28b4dce6db0bdb6d5d38
Getting SHA1 of source init_boot.img ...
Source init_boot.img's SHA1 is: bea42eca0a4e06eac0e876c2e7b9f518ade87874
Extracting SHA1 from magisk_patched_26100_bea42eca_081f1391.img ...
SHA1 embedded in /home/REDACTED/.local/share/PixelFlasher/tmp/magisk_patched_26100_bea42eca_081f1391.img is: bea42eca0a4e06eac0e876c2e7b9f518ade87874
Comparing source init_boot.img SHA1 with SHA1 embedded in bea42eca0a4e06eac0e876c2e7b9f518ade87874 (they should match) ...
Good: Both SHA1s: bea42eca0a4e06eac0e876c2e7b9f518ade87874 match.
Magisk Version: 26.1:26100
Patch time: 5 seconds
The attempt was made yesterday.. 6-20. Is there a log from that date? The ones for panther were when I was using PF for my P7.
--tim
tim1aust said:
The attempt was made yesterday.. 6-20. Is there a log from that date? The ones for panther were when I was using PF for my P7.
--tim
Click to expand...
Click to collapse
OK I see it now.
What is this file? where did it come from?
lynx-factory-23410002.zip
Code:
Selected Firmware lynx-factory-23410002.zip SHA-256: 033c2d0381aec8e4538a393baa9fdd86bfc7f24578fa8e4db9f7d9ea49756948
I have a bookmark in my browser for getting OTA updates ( which I've been doing forever, before PF).. Anyway, there is a link at the top left of the page for Factory images, that's what I downloaded. URL is https://developers.google.com/android/images
Related
{
"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"
}
most part of Introduction from taken sdat2img thread
if you want extract non OTA zip i suggest to use sdat2img tool
FOR AB OTA ZIPS USE THIS SCRIPT AND PAYLOAD EXTRACTOR​
in this tools i made block_image_update() function from android recovery to a binary to run on PC and patch system.img with DAT files on OTA package to update system.img by OTA
also we have apply_patch() function for patching boot.img and other files like firmwares
Introduction
You probably know already that starting from Android 5.x (Lollipop) compiled roms (aosp,cm,stock) are not compressed anymore the way they used to be on previous android versions. On previous versions all content inside /system folder that has to be extracted within our device was either uncompressed (simple /system folder inside our flashable zip) or compressed in a system.img file, which it is a ext4 compressed file; both of these, anyway, were readable and we could see all system files (app,framework, etc).
The problem comes in >=5.0 versions, this method is not used anymore. Why? Because roms started to be always larger, so it is necessary to compress them even more.
What does new Android zips (full roms, but also OTAs) contain?
New Android flashable zips are made this way:
boot.img (kernel)
file_contexts (selinux related)
META-INF (folder containing scripts)
system.new.dat (compressed /system partition)
system.patch.dat (for OTAs)
system.transfer.list (see explanation below)
and other patch files (.p only on OTA zip)​
What does updater-script contains then?
The updater-script uses a brand new function: block_image_update(), this method basically decompresses necessary files inside the device. Let's study it.
From google git source code, if we go inside the new file /bootable/recovery/updater/blockimg.c, we find at the end of it the registration of the function block_image_update() as the method BlockImageUpdateFn() which starts at line 254. Here finally we find all information we need to know about the decompression of the .dat file(s). First file we analyze is system.transfer.list which Google tells us:
The transfer list is a text file containing commands to transfer data from one place to another on the target partition.
Click to expand...
Click to collapse
But what each line means?:
First line is the version number of the transfer list; 1 for android 5.0.x, 2 for android 5.1.x, 3 for android 6.0.x, 4 for android 7.x
Second line is the total number of blocks being written
Third line is how many stash entries are needed simultaneously (only on versions >= 2)
Fourth line is the maximum number of blocks that will be stashed simultaneously (only on versions >= 2)
Fifth line and subsequent lines are all individual transfer commands.
Click to expand...
Click to collapse
all transfer commands is :
bsdiff
*erase
free
imgdiff
move
*new
stash
*zero
BlockImageUpdate is reading system.transfer.list and executing all commands
But BlockImageVerify doesn’t execute * commands, which not to make changes on system.img just verifying update can happen
original sdat2img tool only support "new" command
Ok, but how to Patch the system.img with OTA files?
All instructions are below. binaries are involved. Please read carefully step by step.
You can use/modify these files and/or include them in your work as long as proper credits and a link to this thread are given.
If you have questions or problems
write here
Thanks
- @xpirt , for original sdat2img tool and useful thread
XDA:DevDB Information
IMG Patch Tools, sdat2img for OTA zips, Tool/Utility for all devices (see above for details)
Contributors
erfanoabdi
Source Code: https://github.com/erfanoabdi/imgpatchtools
Version Information
Status: Testing
Created 2017-07-21
Last Updated 2020-01-23
Usage
Code:
./BlockImageUpdate <system.img> <system.transfer.list> <system.new.dat> <system.patch.dat>
args:
<system.img> = block device (or file) to modify in-place
<system.transfer.list> = transfer list (blob) from OTA/rom zip
<system.new.dat> = new data stream from OTA/rom zip
<system.patch.dat> = patch stream from OTA/rom zip
Code:
./ApplyPatch <file> <target> <tgt_sha1> <size> <init_sha1(1)> <patch(1)> [init_sha1(2)] [patch(2)]...
args:
<file> = source file from rom zip
<target> = target file (use "-" to patch source file)
<tgt_sha1> = target SHA1 Sum after patching
<size> = file size
<init_sha1> = file SHA1 sum
<patch> = patch file (.p) from OTA zip
Code:
usage: ./scriptpatcher.sh <updater-script>
args:
<updater-script> = updater-script from OTA zip to patch recovery commands
Example
for example from updater-script of OTA we have:
Code:
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat")
apply_patch("EMMC:/dev/block/bootdevice/by-name/boot:33554432:f32a854298814c18b12d56412f6e3a31afc95e42:33554432:0041a4df844d4b14c0085921d84572f48cc79ff4",
"-", 0041a4df844d4b14c0085921d84572f48cc79ff4, 33554432,
f32a854298814c18b12d56412f6e3a31afc95e42,
package_extract_file("patch/boot.img.p"))
after getting system.img and boot.img from firmware This is equals of previous functions on PC with this tools:
Code:
~$ ./BlockImageUpdate system.img system.transfer.list system.new.dat system.patch.dat
~$ ./ApplyPatch boot.img - 0041a4df844d4b14c0085921d84572f48cc79ff4 33554432 f32a854298814c18b12d56412f6e3a31afc95e42
scriptpatcher.sh will generate all commands automatically from updater script so run it like:
Code:
~$ ./scriptpatcher.sh META-INF/com/google/android/updater-script > fullpatch.sh
check fullpatch.sh your self, you need to provide all images and files in correct name and patch as mentioned in mount and other commands of fullpatch.sh
Building Requirements
For Building this tool you need :
zlib
libbz2
openssl
It currently supports Linux x86/x64 & MacOS, Not tested on Windows.
Compile and Build command:
Code:
make
Youtube
Download links:
GitHub Release
Changelog:
GitHub Commits
Known Bugs/Issues:
Plz test and report
Nice work
Very nice
Sent from my LG-LS997 using Tapatalk
Wow, I tried to apply OTAs manually myself, but never got it to work. Getting the propper tools from you is awesome!
One tiny question though: Does applying/verifying a system update to system.img require a lot of temporary space or memory?
I am running Ubuntu x64 in a VM (VirtualBox) on Windows 10. Verifying a system update doesn't really do much, except keeping the CPU busy.
This is the output of "./BlockImageVerify system.img system.transfer.list system.new.dat system.patch.dat":
Code:
performing verification
creating cache dir cache
cache dir: cache
blockimg version is 3
maximum stash entries 236
creating stash cache/537ed49fb5f6c32dc3d205d78b6084fe54f70cd3/
The cache folder remains empty, there is no harddisk activity and only the CPU is working at 100 %. I interrupted BlockImageVerify after 30 minutes.
daniel_m said:
Wow, I tried to apply OTAs manually myself, but never got it to work. Getting the propper tools from you is awesome!
One tiny question though: Does applying/verifying a system update to system.img require a lot of temporary space or memory?
I am running Ubuntu x64 in a VM (VirtualBox) on Windows 10. Verifying a system update doesn't really do much, except keeping the CPU busy.
This is the output of "./BlockImageVerify system.img system.transfer.list system.new.dat system.patch.dat":
The cache folder remains empty, there is no harddisk activity and only the CPU is working at 100 %. I interrupted BlockImageVerify after 30 minutes.
Click to expand...
Click to collapse
Ah actually yes you need free space on RAM as much as both patch.dat and new.dat sizes
It's on my todo list to fix it, https://github.com/erfanoabdi/imgpatchtools/blob/master/blockimg/blockimg.cpp#L383
How to extract the file system.new.dat
evangelico793 said:
How to extract the file system.new.dat
Click to expand...
Click to collapse
You can find it in OTA zip
Motorola? See this : motorola.erfanabdi.ir
erfanoabdi said:
You can find it in OTA zip
Motorola? See this : motorola.erfanabdi.ir
Click to expand...
Click to collapse
No longer look at the picture
erfanoabdi said:
You can find it in OTA zip
Motorola? See this : motorola.erfanabdi.ir
Click to expand...
Click to collapse
Something Looks Wrong ReCheck inputs Or No Update Available
for moto g4 play 6.0.1
evangelico793 said:
No longer look at the picture
Click to expand...
Click to collapse
Please send picture again
404 not found
evangelico793 said:
Something Looks Wrong ReCheck inputs Or No Update Available
for moto g4 play 6.0.1
Click to expand...
Click to collapse
You are doing something wrong see thread for help and examples
@erfanoabdi
Thank you a ton for these tools!
They work like a charm :good:
I knew there must be a way to do this, but it's definitely above my paygrade.
@erfanoabdi
I've been trying scriptpatcher.sh on various updater-scripts and have noticed some bugs.
If you're interested in looking at the files, let me know and I'll post them.
Q9Nap said:
@erfanoabdi
I've been trying scriptpatcher.sh on various updater-scripts and have noticed some bugs.
If you're interested in looking at the files, let me know and I'll post them.
Click to expand...
Click to collapse
Yeah, there's lots of bugs in that script
I appreciate any kind of help
So far i know :
Only supporting /dev/block/boot.../by-name partitions
Can't mount ext4 in macOS
I disabled verify, but we can verify images
And i haven't tested it so much
If it gets more complicated Maybe we have to rewrite it on python.
erfanoabdi said:
Yeah, there's lots of bugs in that script
I appreciate any kind of help
So far i know :
Only supporting /dev/block/boot.../by-name partitions
Can't mount ext4 in macOS
I disabled verify, but we can verify images
And i haven't tested it so much
If it gets more complicated Maybe we have to rewrite it on python.
Click to expand...
Click to collapse
*removed*
@erfanoabdi
I noticed that there was an update to the source today to enable the bonus file argument.
I tried to create a recovery.img with a boot.img, recovery-from-boot.p, and recovery-resource.dat.
I tried patching to create a new recovery image and also tried patching the boot image in place.
It always returns "Unknown patch file format".
I am able to use these files to create recovery with the on-device applypatch binary, so not sure why it's throwing the "unknown patch file format" error.
Q9Nap said:
@erfanoabdi
I noticed that there was an update to the source today to enable the bonus file argument.
I tried to create a recovery.img with a boot.img, recovery-from-boot.p, and recovery-resource.dat.
I tried patching to create a new recovery image:
#Output:
creating cache dir cache
cache dir: cache
patch boot.img:
failed to stat "recovery.img": No such file or directory
Unknown patch file format
Done with error code : 1
and also tried patching the boot image in place:
#Output:
creating cache dir cache
cache dir: cache
patch boot.img:
Unknown patch file format
Done with error code : 1
I am able to use these files to create recovery with the on-device applypatch binary, so not sure why it's throwing the "unknown patch file format" error.
Any ideas? Is my syntax incorrect?
Click to expand...
Click to collapse
That was chainfire commit changes how can i say "no" to his PR
I didn't had time to check it
I'll check it out when I could
Q9Nap said:
@erfanoabdi
I noticed that there was an update to the source today to enable the bonus file argument.
I tried to create a recovery.img with a boot.img, recovery-from-boot.p, and recovery-resource.dat.
I tried patching to create a new recovery image:
#Output:
creating cache dir cache
cache dir: cache
patch boot.img:
failed to stat "recovery.img": No such file or directory
Unknown patch file format
Done with error code : 1
and also tried patching the boot image in place:
#Output:
creating cache dir cache
cache dir: cache
patch boot.img:
Unknown patch file format
Done with error code : 1
I am able to use these files to create recovery with the on-device applypatch binary, so not sure why it's throwing the "unknown patch file format" error.
Any ideas? Is my syntax incorrect?
Click to expand...
Click to collapse
I've tested recovery-from-boot by chainfire and i can confirm its working
Also i fixed no such file error
Try to compile new source
*edit*
Fixed!
Poison Kitchen IDE
Development preview
{
"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"
}
​
Description
A powerful IDE for android ROM development
Runs native on WINDOWS, MacOS themed.
Its powered by my XanderUI class library for the .net framework
Currently Development preview builds are only available, meaning things may be broken, behave incorrectly or other
Click to expand...
Click to collapse
Features
-Full GUI coded in C# for fast runtime
-XanderUI based controls(My C# class library)
-Based on .net 4.5
-Support for every single android version
-Unpack rom from (.zip, .tar, .md5, .img, aml_upgrade_package)
-Pull all required files from device(root needed to copy kernel block)
-Adb, fastboot and drivers installater
-ROM information
-Explorer
-Deodexing(4.4.4 and lower ATM)
-Unpacking the kernel
-Converting file_contexts.bin to standard text
-Kernel explorer
-Repacking kernel
-Logging
-Auto-generating updater-script
-Use generic symlinks if files detected
-Use generic file contets if the kernel does not contain file_contexts
-/data/app auto transition to new rom(somewhat working)
-Wipe data excluding /data/media(/sdcard path)
-Auto kernel block detection
-Auto mounting /system and /data
-Packing rom
-Signing rom
-Updater-script editor
-Extansion support
-Emulated exension scripts(applied via C#)
-Degapps extension
-Deknox extension
-Custom emoji extension
-Enable sony apps extension
Click to expand...
Click to collapse
Features not yet implemented
-root via magisk(systemless) and superSU(standard)
-init.d
-deodexing 5.0 and up
-adbd insecure
-init.d tweaks
-build.prop tweaks
-change display I.D
-add sysrw/ro binary
-logging needs tweaking
-loading rom information updated in the background
-Unpacking RUU as project(HTC)
-Unpacking TFT as project(SONY)
-Unpacking system.dat(sparse)
-Setting your actual device as the project and apply changes in realtime
-/data/app auto transition to new rom
-Kernel may not unpack
-Convert line endings in explorer context menu
-Inbuilt file editor(with EOL auto-detection)
-Boot animation player/changer
-Auto flash rom with ORS(TWRP)
-Bluestacks as rom
Click to expand...
Click to collapse
Settings
Load settings()
-Set default startup project or startup menu
-Enable/disable logging
-Stop logger from detecting files or folders added, deleted, changed or moved
Installation settings()
-Change romname
-Change installation type(autodetect on unpack, User generated, Tool generated)
-Change file contexts method(Auto, extracted from kernel, assumed)
-Enable/disable safewipe
-Enable/disable data/app auto transition
-Enable/disable autodetect ernel blockpath(add path below)
Pack settings()
-Change compression level
-Add signing method(pack into presigned, sign on zip, none)
-Change java heapsize
-Exclude files and folders from being packed/detected by IDE
Default program settings()
Change default program to open image files
Change default program to open video files
Change default program to open audio files
Change default program to open prop files
Change default program to open archive files
Change default program to open jar/apk files
Change default program to open other type files
Current version and updates()
Cleanup settings()
Click to expand...
Click to collapse
License
GNU GPL V3
Downloads
Downloads page
XDA:DevDB Information
Poison Kitchen IDE, Tool/Utility for the Android General
Contributors
Ricky Divjakovski
Version Information
Status: Testing
Created 2018-04-19
Last Updated 2018-04-19
Creating extensions and documentation
Code:
Description -
As extensions are a great adittion to the IDE, whats the use if you cant make your own for automated building?
Information you need to know -
The tool looks for the file "extension.info".
In the extension.info file you will specify the extension name, description and the poison shell script file(.psh).
Package the folder containing the extension as a zip archive
------------------------------------------------------------------
Entension index
------------------------------------------------------------------
Sample extension -
https://github.com/Ricky310711/Poison-Kitchen-Extension-Example
extension.info -
Lines will only be read if starting with "Name", "Description" or "Run"
-------------------- code exmpla
# this sets the extension name
Name:Fake optimizer
# this sets the extension description
Description:Do not apply this to rom, its a fake extension to show an example
# this is the poison script to run(must be in same directory)
Run:FakeOpt.psh
------------------------------------------------------------------
Scripting language(.psh file)
------------------------------------------------------------------
Information
-Must be linux EOL(\n)
-Anything but recognised 1st args are ignored
-Any errors will be ignore by the shell
-Use full paths asif you are in the root(/)
Extracting content to rom
---------- code example
EXTRACT|myFolder
1st arg states we are extracting(copying) a folder to the rom
2nd arg is the folder to extract(must be in same directory as extansion)
NOTE: This will extract the folder to the root of the rom
Changing a line in a file
---------- code example
CHANGE|START|/system/build.prop|ro.product.device=|THIS IS STARTS TEST
1st arg specifies we are changing a file
2nd arg specifies where on a line to search for the string(arg4)
3rd arg specifies the file to change
4th arg specifies the string to look for
5th arg is what you would like to replace the line with
The second arg can be START, CONTAINS or END
Appending a file
---------- code example
APPEND|TOP|/system/build.prop|# A TEST FOR APPENDING TOP
1st arg specifies we are appending a file
2nd arg specifies if we are appending at the TOP or BOTTOM
3rd are is the file to append
4th arg is the content to append
Remove a line from a file
---------- code example
REMOVE|/system/build.prop|# end fota properties
1st arg states we are removing a line from a file
2nd arg specifies the file
3rd arg is the string to look for in the line
Delete a file or folder
---------- code example
DELETE|/system/preinstall
Pretty straight forward, will delete a file or folder called "preinstall" from /system/
Create a file or folder
---------- code example
CREATE|DIRECTORY|/preinstall
arg 1 states we are creating something
arg 2 specifies if a FILE or FOLDER
arg 3 is the file or folder to create
Rename a file or folder
---------- code example
RENAME|/system/bin/am|amRenamed
1st arg specifies we are renaming a file or folder
2nd arg is the file or folder
3rd arg is the new name
Changelog
Development preview 2
-Added pull rom from device in setup
-Smoother nvigation
-XanderUI 1.6.0 integration
-Message boxes are now themed like the app
-Extensions now show progress upon running
-Deodexing up to Android 4.4.4 implemented
Development preview 1
-initial release
reserved3
supports all versions of android and all devices, no manual input needed.
dev preview 3 possibly tommorow
Yay now I can at least try to build my own g6 ROMs. Nice work.
development on hold until the 30th as im on holiday, i have been dedicating little time to this as internet here is extremely slow
Magisk and SU support added aswell as deodexing 5.x > 6.0
Also working on disabling signature verification, adding sysrw(as binary)
hi, im trying out the program, it never completes the extraction, and the progress icon starts at 53% do i need to do anything when trying to start the program.
i haVE TRIed running as administartor and without running as admin.
thanks
Twisted714 said:
hi, im trying out the program, it never completes the extraction, and the progress icon starts at 53% do i need to do anything when trying to start the program.
i haVE TRIed running as administartor and without running as admin.
thanks
Click to expand...
Click to collapse
A dialog will more then likely poppup requesting permission to run imgextractor.exe, be sure to accept that to complete the process
Ricky Divjakovski said:
A dialog will more then likely poppup requesting permission to run imgextractor.exe, be sure to accept that to complete the process
Click to expand...
Click to collapse
i am attaching some pics to what happens.
please advise. thanks
there are a couple more that are insignificant
Twisted714 said:
i am attaching some pics to what happens.
please advise. thanks
there are a couple more that are insignificant
Click to expand...
Click to collapse
Could you please PM me with pics of the firmware your selecting or even a link?
I've gone ahead and tried this. I pointed the app to my system.img (not the fastboot zip) and ended up with "error extracting". Tool looks promising. ROM is available for download here:
http://en.miui.com/download-333.html
I extracted it and used the images/system.img
oreo27 said:
I've gone ahead and tried this. I pointed the app to my system.img (not the fastboot zip) and ended up with "error extracting". Tool looks promising. ROM is available for download here:
http://en.miui.com/download-333.html
I extracted it and used the images/system.img
Click to expand...
Click to collapse
Im going to test now, if the firmware has system.transfer.list, and system.dat, it will not be able to be unpacked until i make a native library or extension to perform the operation as i think it would be extremely stupid for the need to have python installed to run.
The only reason i havent rebuilt smali/baksmali etc is 1. Would take me months, 2. we are modifying a system that relies on java to operate.
in future, hefty operations like unpacking etc, will be coded in ASM/C code for faster operation, Im planning on making the whole project open source to allow changes and fixes submitted by other developers, So if anyones interested let me know and ill upload the source code(Written in C# for the .net 4.5 framework)
Ricky Divjakovski said:
Im going to test now, if the firmware has system.transfer.list, and system.dat, it will not be able to be unpacked until i make a native library or extension to perform the operation as i think it would be extremely stupid for the need to have python installed to run.
The only reason i havent rebuilt smali/baksmali etc is 1. Would take me months, 2. we are modifying a system that relies on java to operate.
in future, hefty operations like unpacking etc, will be coded in ASM/C code for faster operation, Im planning on making the whole project open source to allow changes and fixes submitted by other developers, So if anyones interested let me know and ill upload the source code(Written in C# for the .net 4.5 framework)
Click to expand...
Click to collapse
Not sure if this helps but I've run Imgextractor directly on my system.img with this result:
Code:
Mi-A1-Repository>Imgextractor Mi-A1-Repository\Roms\Fastboot\tissot_images_V.9.5.10.0.ODHMIFA_8.0\images\system.img
ImgExtractor version 1.3.6 <Created by And_PDA (Based on sources ext4_unpacker)>
Extractor for images in EXT2\EXT3\EXT4\YAFFS2\CRAMFS filesystem formats
support SPARSE\SIN\MOTO structure formats
Open image file Mi-A1-Repository\Roms\Fastboot\tissot_images_V.9.5.10.0.ODHMIFA_8.0\images\system.img (size 3221225472 bytes) successfull...
Analize format of file. Please wait...
Found SPARSE FORMAT
Found EXT4 FORMAT
free space in image 188895232 bytes
Extract started. Please wait...
Extract 750 folders and 6306 files successfull
Found 386 symlink files
File stats (uid, gid, permission) save to Mi-A1-Repository\Roms\Fastboot\tissot_images_V.9.5.10.0.ODHMIFA_8.0\images\system__statfile.txt
Extract finish success
Press Enter to continue...
oreo27 said:
Not sure if this helps but I've run Imgextractor directly on my system.img with this result:
Code:
Mi-A1-Repository>Imgextractor Mi-A1-Repository\Roms\Fastboot\tissot_images_V.9.5.10.0.ODHMIFA_8.0\images\system.img
ImgExtractor version 1.3.6 <Created by And_PDA (Based on sources ext4_unpacker)>
Extractor for images in EXT2\EXT3\EXT4\YAFFS2\CRAMFS filesystem formats
support SPARSE\SIN\MOTO structure formats
Open image file Mi-A1-Repository\Roms\Fastboot\tissot_images_V.9.5.10.0.ODHMIFA_8.0\images\system.img (size 3221225472 bytes) successfull...
Analize format of file. Please wait...
Found SPARSE FORMAT
Found EXT4 FORMAT
free space in image 188895232 bytes
Extract started. Please wait...
Extract 750 folders and 6306 files successfull
Found 386 symlink files
File stats (uid, gid, permission) save to Mi-A1-Repository\Roms\Fastboot\tissot_images_V.9.5.10.0.ODHMIFA_8.0\images\system__statfile.txt
Extract finish success
Press Enter to continue...
Click to expand...
Click to collapse
Found the error, the img file is of a wierd format, as its named system.img, it actually contains files from the root, so within the system.img the the root of the image is actually the root of the device rather then the root of the system partition, its extremely odd but none the less extremely simple to fix
Issue is already fixed and will be included in dev preview 3, that is expected for public release in a day or so with much more additions
Ricky Divjakovski said:
Found the error, the img file is of a wierd format, as its named system.img, it actually contains files from the root, so within the system.img the the root of the image is actually the root of the device rather then the root of the system partition, its extremely odd but none the less extremely simple to fix
Issue is already fixed and will be included in dev preview 3, that is expected for public release in a day or so with much more additions
Click to expand...
Click to collapse
Yeah. I found it odd that the system.img had a /system directory in it. Awesome! Can't wait
Ricky Divjakovski said:
Could you please PM me with pics of the firmware your selecting or even a link?
Click to expand...
Click to collapse
its on mega.
https://mega.nz/#!dCA2mAYS!-GrKWuuTNODaYEbt3LWiw4LJzxkrz5wI3T94mQ4PU90
it is a android 6 to android 7 full update. its installed, but i am trying to learn cobble together a rom. this img is for a zoomtak upro, i have found today an image for the uplus/vplus. it has much more stuff in it.
thanks
Twisted714 said:
its on mega.
https://mega.nz/#!dCA2mAYS!-GrKWuuTNODaYEbt3LWiw4LJzxkrz5wI3T94mQ4PU90
it is a android 6 to android 7 full update. its installed, but i am trying to learn cobble together a rom. this img is for a zoomtak upro, i have found today an image for the uplus/vplus. it has much more stuff in it.
thanks
Click to expand...
Click to collapse
I will check it when i get home, if its an upgrade package, i cannot ad support for it..
THIS IS YOUR FIRST WARNING (WILL BE REITERATED PLENTY OF TIMES!) IN BIG RED BOLD LETTERS - THESE FILES ARE FROM/FOR THE USA ("XAR") REGION, SM-P610 WIFI MODEL ONLY!
(with the exception of the Odin utility, as well as possibly the modified boot splash screen, which may work on other variants, though untested and done solely at your own risk - read all the notes!!)​
I already went through the work, so I figured I would share these files for those who also own the same exact tablet. Again, it's for the USA/XAR region Samsung Galaxy Tab S6 Lite WiFi Model ONLY - "SM-P610" / "gta4xlwifi". LTE model is a different variant; do NOT flash the stock firmware files to that device! Also, sorry, I will not support or answer questions for other variants (other than what I will mention in this OP). Downloading firmwares for other variants will be a huge PITA, and I don't have / pay for any "premium" accounts which would allow me to quickly download the huge firmware files. I'm only sharing these I'm posting because I already took the time to acquire and archive them for personal usage, and might as well share them for those who own the same device / variant.
Use these files at your own risk, and only flash if you know what you're doing!! I'm not responsible for any problems user may incur from usage of these files, the usual warnings apply, etc. This device is just a backup / playaround device for me, and so it doesn't get daily usage out of me, nor will I likely be very active on this subforum (sorry! just being honest). Also, I immediately installed LOS on my device anyway, so I don't run stock ROM myself and therefore won't be sharing pre-patched Magisk boot images either. Sorry to those who are used to that from me =)
So anyway... what's in this post?
Odin3 v3.14.4 (version I've been using on this device, and working perfectly fine as of this initial posting)
Stock firmware zips for USA/"XAR" Region SM-P610, WiFi Only
Modified BL file (Odin-flashable), to remove the warning boot text
Odin3 v3.14.4:
I posted this in another thread, but figured I would also link to it here so it's easy to find in one place. This worked perfectly fine for me to root / install TWRP / flash BL files, etc.
Download Link: https://www.androidfilehost.com/?fid=10763459528675582443
Stock Firmware Files:
USA/XAR WIFI ONLY! October 2020 Update - Firmware Version P610XXU2BTJ5
Download Link: https://www.androidfilehost.com/?fid=10763459528675592742
USA/XAR WIFI ONLY! September 2020 Update - Firmware Version P610XXU2BTI3
Download Link: https://www.androidfilehost.com/?fid=10763459528675592159
Firmware files for other variants, see this post. Follow the links, use the resources, consider the context for other variants: https://forum.xda-developers.com/showpost.php?p=83083249&postcount=2
Modified [BL-slot] Odin-Flashable File To Remove Warning Splash Screen Text:
My Thoughts On This...After unlocking the bootloader and flashing non-stock images, we all know we end up with that annoying, ugly splash screen screaming that the device is modified. Most of us modifying our devices understand the security implications involved, and ironically choose to modify our devices to increase security in other ways. Yet, these warning splash screens, in the unfortunate event of possible theft, may very well end up being the reason a more tech-savvy thief is able to break into the device, or find someone who can. So, thanks to users' posts Awesomeslayerg's hint and blascogm's guide, I quickly came up with an Odin-flashable file to change the splash screen, as seen below:
(if the pic doesn't show, probably the imgur link I used is dead, but I also attached it to this post)
{
"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"
}
I know some people may be thinking "why not just remove the PRESS POWER KEY TO CONTINUE line completely and have it stay at the normal boot screen seamlessly the whole time", and the reason I decided not to do this is because it generally wouldn't make the average person suspect the device is modified, and it's still good for us to know that it's at the boot stage where we can hit the power key to skip the ~10 second timeout. It's exactly the same image, so it's still very seamless and stock-like. I even took the time to center the power key text exactly, by the pixel, from left to right and from top bottom relative to the knox and android logos.. ; )
And if it really bothers you that much, follow the guide I linked above and do it yourself. =)
I should also mention that, for our devices, the .bin.lz4 file that needs to be decrypted is actually "up_param.bin.lz4" and not "param.bin.lz4" as suggested in the guide, as it's for a different device. You will need the lz4 utility (check Awesomeslayerg's thread, or google lz4 github) to decrypt the lz4 file to a regular bin file, and then you can extract and/or replace the .jpg files using an archiver program (I recommend 7-zip for this).
The hash checksums for every single file/jpg in each up_param.bin were identical between the September and October firmwares. Therefore, at least as of this posting, the same modified Odin-flashable file will work on either firmware version, and likely future versions until they make any significant changes. I did test this myself too btw. Also, if you look at the structure and contents of the up_param.bin file for yourself, you'll see that they are simply .jpg files containing the screens, backgrounds, and text you're all familiar with when going into bootloader / download mode. Assuming they follow the same file naming structure, I suspect you can probably flash this to other variants, although it will change the text language to English (assuming they localize the bootloader / download mode text per every region; I have no idea about this as I only own US variants). To see what I'm talking about, here's a quick screenshot (better resolution pic, and just in case imgur link dies, also attached to this post):
Now that I (hopefully) tricked you into reading this entire section so that you now have some basic understanding of how it works before proceeding to flashing the warning text removal mod, here are the instructions / link for install:
- Download the .tar file provided below.
- Boot device into Download mode.
- Place .tar file into bootloader [BL] slot in Odin and flash.
Download Link: https://www.androidfilehost.com/?fid=10763459528675592179
To revert back to stock splash screen with warning text, for whatever reason:
Pull the stock up_param.bin.lz4 from the stock firmware file (from the BL****.md5 file within the firmware zip).
- Convert it to up_param.bin uzing lz4 utility.
- Add up_param.bin to an archive as .tar file, uncompressed (recommend using 7-zip).
- Flash the .tar file, which should contain only the stock decrypted up_param.bin file, in Download mode using Odin in the BL slot.
I uploaded my custom jpg's, as well as the stock untouched jpg's, for those that are curious or want to edit them further. Feel free to snag them here: https://www.androidfilehost.com/?w=files&flid=320350
* As we can see, we're only modifying the .jpg files provided by up_param.bin, so it's a relatively harmless process (unlike modifying aboot files in the old days of HTC devices, which if done improperly could literally result in an unrecoverable brick). But even so, please only flash if you know what you're doing and can recover from any potential mistakes or errors.
Not sure if there were any changes since the September / October 2020 firmwares, but here's a new one directly modified from the March 2021 (Android 11) firmware base:
NEWEST DOWNLOAD, BASED ON 2021-03 FIRMWARE:
https://www.androidfilehost.com/?fid=14943124697586346609
And another
Hi,
Thanks for these resources. I'm actually not at these steps yet. I'm having trouble gaining access to the OEM Bootloader Unlock option in developer options. Here are things I've tried already based on what I researched before my attempt.
Android 10 is the current OS installed after unboxing.
1. Disable Automatic Date and time
2. Select a date more than 7 days prior to current date of attempt.
3. Under Settings > About Phone > Software Information. Select/Tap Build Number 7-8 times to unlock Developer Option.
4. Disable Auto Update System (Apply Updates When Device Restarts) - *This was somehow already disabled the first time I entered Developer options*
5. Under Software Updates > Disable Automatic Updates -*This was also already disabled on unboxing and it says Automatically download updates over Wifi. It does not say Automatic Updates*
6. Reboot device and return to Developer Options after booting to OS.
7. The OEM Bootloader Unlock option should appear greyed out at this point. Toggle it to unlock bootloader with consideration that it will wipe the device data.
These are the steps I've found and tried with no success in gaining access to the Bootloader unlock option. I am also certain that my device is the international model SM-P610 with Exynos chipset and Mali-G72 GPU. Something else to note, I did uncheck many default options tied to improving privacy on the device before attempting the steps to gain access to the bootloader unlock option. I do not know if that would make a difference. If you recognize anything wrong with the steps I've tried already, please let me know where I'm going wrong or where I can find the correct way to unlock the bootloader. I've been posting in other threads, but nobody seems to be replying to me. Any help will be appreciated.
Hi
I've flashed your modded file on my PHN (Netherlands), no problems at all working ootb!
Hi. I used blascogm's guide for my P615 with latest firmware for SEC UI 3.1and all are OK! Thanks for all.
Add. I add link . Flash via Odin(BL).
https://androidfilehost.com/?fid=14943124697586347282
i5lee8bit said:
Not sure if there were any changes since the September / October 2020 firmwares, but here's a new one directly modified from the March 2021 (Android 11) firmware base:
NEWEST DOWNLOAD, BASED ON 2021-03 FIRMWARE:
https://www.androidfilehost.com/?fid=14943124697586346609
Click to expand...
Click to collapse
I flashed ths when I'm running lineageos 18.1 annd this is the only mod that worked for me
Thanks for posting your images and linking to the guide, worked perfectly and the images just fit to the pixel <3
Confirmed working as of March 2022. Device is running base P610XXU2DUL9. Thanks for the hard work.
can you make one for SM-P613 model plz?
repacksuper
===========
Copyleft uluruman 2021-2022
(for LINUX/WSL only)
This is the minimalistic set of tools + a script for Linux for the automated
ground-up repacking and flashing of the Samsung Galaxy super.img, replacing
the stock Android system with something much less intrusive and obtrusive
(e.g. LineageOS). Or just some other GSI (Generic System Image).
Additional included scripts (since v1.1) simplify flashing of stock firmware or
separate image files under Linux using Heimdall.
Theoretically should work for any Samsung A-series phones, and may be even for
some others. Tested on SM-A127F/DSN made in India and Vietnam and SM-A325F/DS
made in India, on Debian Linux 11 x64. There are reports of successful flashing
of SM-A127M, SM-A032M and SM-A226B.
Why this method?
----------------
Repacking of super.img is the only method which allows changing of the phone's
operating system without screwing up the Verified Boot (VB) protection
mechanism. Keeping the VB allows you to be sure that everything besides the
platform was indeed compiled by Samsung and wasn't tampered with, no matter from
where you downloaded your stock firmware.
The other reason is that although there are alternative methods of changing the
OS, for phones with dynamic partitioning and no working version of TWRP
available they may be even more complicated than repacking of super.img
externally by this script.
Requirements
------------
Install the following tools from the official repositories of your Linux distro:
simg2img xz-utils lz4 unzip gzip jq file
Basic instructions
------------------
repacksuper.sh: main script for changing your phone's operating system
heimdall_flash_stock.sh: script for flashing stock firmware under Linux
heimdall_flash.sh: script for flashing any custom image file under Linux
Just run a script without any arguments to see help.
Extra tools used (x64 binaries and sources included)
----------------------------------------------------
GitHub - LonelyFool/lpunpack_and_lpmake: android super.img tools
android super.img tools. Contribute to LonelyFool/lpunpack_and_lpmake development by creating an account on GitHub.
github.com
GitHub - amo13/Heimdall: Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices. This is a fork of the original repository with a few crucial pull requests merged.
Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices. This is a fork of the original repository with a few crucial pull requests merged....
github.com
Additional notes
----------------
The included binaries for the lpunpack, lpmake and Heimdall were compiled for
the x86_64 architecture. If your PC architecture is different (e.g. x86 32-bit
or ARM) you have to compile these tools yourself. The full source code is
included (or otherwise available on GitHub).
Spoiler: Changelog
0.9: Initial release
0.91: Non-sparse new system is now correctly moved into the super dir
0.91a: Bug in the new system file format checking fixed
0.91b: Better support for spaces in paths
0.92: Added checking for system requirements and an optional parameter for
setting of the final tar archive name.
0.92a: Fixed file ownership issues inside the tar distribution archive
0.93: Added support for SM-A325F. Several minor improvements.
0.94: Added support for gzip-packed GSI images. Packing into .tar is now done
without question if the command line parameter is given. Tar parameter
now can include the full path. Without the full path the default tar
location is now the same as the GSI. Several other minor changes.
1.0: Finally added working native Linux flashing using Heimdall (HUGE thanks
to amo13 and Benjamin Dobell). Two new options: using empty product.img
and silent (non-interactive) mode. Colored text. Bugfixes and minor
changes.
1.01: Option to specify the SUPER partition name manually (needed for flashing
SM-A127F with Heimdall). Now it is possible to place output .img and .tar
files in any directory and give them any name. Text terminology a bit
clarified, help text expanded. Done many internal optimizations,
additional sanity checks and minor changes.
1.02: Support for SM-A032F/M and similar firmwares with non-packed super.img.
Support for firmwares with/without additional partitions. Support for
arbitrary partition group names. Very experimental option to use empty
system_ext.img for additional privacy (applicable to some phone models/
regions). Lots of minor fixes.
1.03: Multiple .img files are now supported in GSI archive files (one of them
should be system.img in that case), e.g. Android AOSP zip files are now
supported directly. The logic of flashing with Heimdall now includes more
complex cases, such as flashing in two steps with a reboot. Unnecessary
code in GZ unpacking removed. Some other small fixes and optimizations.
1.1: New scripts heimdall_flash_stock.sh and heimdall_flash.sh added.
Lots of refactoring in repacksuper.sh (because of that there may be some
bugs left), improved and clarified UI logic, changes in where the files are
now placed (see help for details), direct work with stock Zip firmware
files, lots of minor changes.
1.11: Colored text now should be correctly displayed in almost any shell that
supports it except if it's explicitly disabled with NO_COLOR.
1.11.1: heimdall_flash.sh now can flash Super partitions unconditionally in one
step when using both the -s parameter and manually specifying parition
name (e.g. SUPER for SM-A127F).
1.12: The heimdall_flash_stock.sh script was significantly upgraded with lots of
new features. Now it theoretically allows upgrading of stock firmware
without erasing user data, keeping the GSI and custom recovery, etc.
(although it's not that straightforward, read the help for details).
A couple of fixes in the other scripts.
1.12.1: changed unlz4 to lz4 -d, as some distros don't have the needed symlink
1.13: In repacksuper.sh support added for the Vendor DLKM and ODM DLKM
partitions, as well as the experimental -v option to add or replace Vendor
DLKM with a custom image. A couple of minor fixes.
1.14: Greatly improved logic of heimdall_flash.sh, now it's possible to specify
both or either custom partition name and custom file name, and acquiring
PIT from device is done only when it's needed. Versioning scheme of the
scripts was unified: the script that was updated receives the updated
version number of the whole pack, the rest retain the old numbers.
1.15: up_param_tool.sh script was added: it allows altering of the boot
sequence images (logo, "not official" warning, etc.), as well as the
Recovery and Download internal graphics. Happy hacking, but please pay
attention to the warning displayed after extracting the JPEG files.
A couple of minor fixes in the other scripts.
1.15.1: Bug with failing LZ4 uncompression fixed in repacksuper.sh and
heimdall_flash_stock.sh.
1.15.2: Added the Ctrl+C trap in heimdall_flash_stock.sh, so now the temporarily
renamed files are correctly renamed back in case of flashing being
aborted with Ctrl+C. Upgraded Heimdall with the git pull requests, but
it seems those still do not cure the relatively rare issue when flashing
specific files gets completely stuck at some point.
1.15.3: The "file" tool used to identify PIT files was replaced with direct
reading of the file header as the first method proved to be unreliable.
1.15.4: Fixed a bug in heimdall_flash.sh (missing g flag in sed)
1.15.5: Fixed the compatibility issue with the older LZ4 compressors
1.15.6: Fixed compatibility issues with systems where /bin/sh is Bash, such as
ArchLinux
1.15.7: repacksuper.sh: fixed using the existing "repacksuper" dir as source,
also in this mode you can now specify "-" as new system image to reuse
everything inside the "super" subdir. New experimental -w parameter.
All scripts: the Ctrl+C trap now switched on and off the correct way.
Several other fixes.
1.15.8: Fixed using the heimdall_flash_stock dirs as source for repacksuper.sh.
A couple of other fixes.
1.15.9: heimdall_flash_stock.sh: fixed skipping of duplicate partitions (e.g.
vbmeta) for some shells; fixed upgrade-flashing of Galaxy A32 (default
behavior).
Spoiler: Known issues
During the script run you can see several "Invalid sparse file format at header
magic" warnings, just ignore them.
For some firmware files Heimdall may not work at all (freeze indefinitely or
exit with an error), in that case you have to resort to Odin. In many cases
Heimdall freezes when uploading files for some time, but that does not mean it
is completely frozen, just be patient.
In LineageOS, Dot OS and some other GSIs I tried on SM-127F the touch screen
remains not responsive for about 6 seconds after waking up. The problem is not
present at least with SM-127F/DSN phones made in India, but present at least in
those made in Vietnam. Another problem in the most, if not all, GSIs is that the
MTP USB file transfer does not work (at least on Linux) because of the "wrong"
(Samsung's instead of Google's) default MPT driver used by the kernel.
Both of the aforementioned problems can be solved by installing the fixed and
recompiled kernel.
For the last problem alternative solutions include using apps such as
Warpinator, Syncthing or ftpd.
Spoiler: Food for thought
When choosing a GSI to install I really don't recommend using ones which include
GApps and therefore use any of the Google services. Don't let corporations
gather your data. You bought the phone and from now on it should be all yours,
with all of its data, like a PC in the good old days. You own your device, and
nobody has the right to stick their nose into how you use your phone, gather any
statistics and push you any ads. You always have a choice to turn down
privacy-unfriendly stuff, the price of that "inconvenience" is actually
ridiculous. From my point of view, there is simply no point in using non-stock
systems if they are still littered with the privacy-unfriendly bloatware.
For the step-by-step guide (slightly outdated) read this and this post. Also be sure to read this post concerning the importance of optics.img. Concerning the up_param_tool.sh be sure to read this post.
The included binaries for the lpunpack, lpmake and Heimdall were compiled for the x86_64 architecture. If your PC architecture is different (e.g. x86 32-bit or ARM) you have to compile these tools yourself. The full source code is included (or otherwise available on GitHub).
Latest stable combinations of stock firmware and LineageOS (updated February 5, 2023):
SM-A127F: A127FXXU7BVI4 + LineageOS 20.0-td 20230115 arm64 bvS
SM-A325F: A325FXXU2CVK3+ LineageOS 20.0-td 20230115 arm64 bvS
Some recommendations (updated February 5, 2023):
If you are a newbie and don't know how to do unlock the bootloader and other such stuff, here is a good guide by LAST_krypton (follow the "Unlocking the booloader" section) or a shorter guide by cldkrs.
First flash the phone with the whole set of stock firmware using the heimdall_flash_stock.sh (Linux only) script with the -d parameter: the latter forces flashing the unsafe partitions, which are needed for complete re-flashing.
If you're on Windows use Odin instead. Although there is a "leaked" Linux version of Odin, it's still closed-source (of course), so I don't recommend using it on your main Linux PC. For using the Windows version of Odin on Linux you have to either use Windows in QEMU (tested and works) or probably Wine (untested). When using QEMU remember to add the SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="685d", MODE:="0666" line to the udev rules (e.g. /etc/udev/rules.d/30-qemu.rules) to enable the write access to the phone.
Sometimes Heimdall cannot flash the stock firmware and gets stuck at some particular file. Although you can successfully flash such a firmware using Odin, I recommend to better to find another firmware, may be one release older, because that may indicate some sort of incompatibility with your particular version of the phone.
The stock firmware comes in different revision numbers (also known as the baseband version), which are upgraded about once a year. Generally it should be beneficial to use the latest revision, but note that once you have upgraded it to a later revision there is no way back (at least known to me). In case you want to experiment with flashing of special kernels and other flavors provided by the XDA developers, if possible, you should probably stick to the very first revision.
If you already have the bootloader unlocked (OEM unlock) then after flashing the stock firmware there is no need to set up the Android, just go straight into the download mode again and flash the repacked super.img.
When downloading LineageOS or any other GSI select the normal arm64 bvS version, not vndklite version.
After flashing the OS go into the Recovery mode (hold volume up and power when rebooting) straight away and do the Factory reset. If you cannot get into the Recovery mode be sure to connect the USB cable before trying to.
If flashing with Heimdall completely freezes at some point make sure you've downloaded and repacked the correct arm64 b or a/b GSI and not arm and not a or a-only variant. If "sw rev check fail" message appears on the screen at some point just ignore it.
You can forcefully reboot your phone at any time, even if it seems bricked, by holding the volume down and power buttons for several seconds.
To upgrade your system to the recent version of the same OS just repackage it again using the same script and flash it normally. If the phone does not boot, get into the Recovery mode and try wiping the Cache partition (all your apps and settings should remain intact).
Most probably you don't need TWRP or any other 3rd party recovery tool at all, as the stock recovery tool works fine for just the factory reset after flashing the super file.
Try to avoid using Magisk if you just want to install another OS and nothing else. It is also not needed for LineageOS bvS version as it already has the su utility integrated, you just need to install the additional Superuser app by Pierre-Hugues HUSSON from the F-Droid store (although it's very old it works just fine).
It's possible that SM-127F/DSN internally is not A12 but actually M12, at least most of the tools and kernels made for M12 work on SM-127F/DSN while those made specifically for SM-125 and even other SM-127 versions do not. Therefore you can find more relevant info and tools in the corresponding XDA thread (my script is still remains relevant though).
I should test this for a127f
Bugs fixed: v0.91 & v0.91a
Bug fixed: v0.91b
Added the "file" utility to the list of requirements, updated readme.txt.
Thanks A LOT, this works! I am finally able to run LineageOS on my phone!
For Windows 10+ users: WSL runs this script just fine with a few additional steps.
1. Install WSL 2 and any Linux distribution from Microsoft Store
2. Run the distribution to finish setup
3. Install the required packages from the post (sudo apt install for Ubuntu/Debian)
4. Shift + Right Click in the folder where you have the script, the AP and the GSI packages
5. Open Linux shell there
6. Unpack & run script as stated in its help
Voila!
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
jadfa said:
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
Click to expand...
Click to collapse
It is totally OK
jadfa said:
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
Click to expand...
Click to collapse
Yes, it is fine. These are just warnings produced by lpmake, they can not be suppressed. I could only suppress all the stdout/stderr from lpmake but it's no good in case of more serious warnings.
Updated to v0.92 with a couple of minor improvements.
{
"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"
}
What should I do next with the raw file?
"Unknown super file format" is this how it should be?
ANDARXapi said:
View attachment 5490897What should I do next with the raw file?
"Unknown super file format" is this how it should be?
Click to expand...
Click to collapse
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
uluruman said:
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
Click to expand...
Click to collapse
The raw file opens as a picture
uluruman said:
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
Click to expand...
Click to collapse
run without sudo: 168: ./lpunpack_and_lpmake/lpunpack: Permission denied Cannot correctly unpack the super file. Exiting ...
I managed to fix the script, you just need to give chmod +x rights to the files in the folder "lpunpack_and_lpmake": lpunpack, lpmake, lpflash, lpdump, lpadd
ANDARXapi said:
I managed to fix the script, you just need to give chmod +x rights to the files in the folder "lpunpack_and_lpmake": lpunpack, lpmake, lpflash, lpdump, lpadd
Click to expand...
Click to collapse
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
uluruman said:
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
Click to expand...
Click to collapse
Okay, I'll test it tomorrow, today I want to relax at the computer all day
uluruman said:
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
Click to expand...
Click to collapse
Checked, it works right away
Is there a way to install magisk and root?
Android 11 (Go Edition)
Modified Stock ROM​
{
"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"
}
Assurance Wireless
KonnectONE Moxee m2160
4G-LTE Smartphone
Model No. MH-T6000​
OVERVIEW:
This is a heavily modified build of the stock Android 11 (Go Edition) ROM which comes preinstalled on the KonnectONE Moxee m2160 smartphone. Please note that, while flashing this ROM will not network unlock your device, the ROM does include added support for most GSM based providers on devices which have previously been network unlocked.
In a nutshell, this modified build focuses on the removal of bloatware and a slimmed-down, more responsive stock OS experience. In addition, once installed, the ROM supports full R/W mounting of all logical partitions encompassed within /super. (The unmodified stock ROM, notwithstanding Magisk systemless root, restricts proper R)W mounting of these partitions due to the stringent codebase changes which implemented the dynamic partition scheme back with the release of Android 10.) This ROM also disables force encryption to /userdata (DFE), disables AVB/dm-verity, and includes several mods for improved performance and responsiveness. While certainly nothing special in terms of custom development for the Moxee m2160, this ROM should provide users with a sufficient daily driver ROM with an optimized stock feel.
FEATURES & BUILD INFO:
• Based on firmware build MH-T6000V1.0.0B010
• Kernel version: 4.19.157-perf
• Security patch level: March 5, 2023
• GMS version: 11_202111.go
• VNDK version: 30
• Quick boot sequence
• Systemless root via Magisk v26.1
• Enabled Power Stamina mode for better battery life
• /system mounts R/W
• /system_ext mounts R/W
• /product mounts R/W
• /vendor mounts R/W
• Force encryption of /userdata disabled (DFE)
• OTA notifications & persists disables
• AVB/dm-verity disabled
• Stock launcher locked in memory
• Zipaligned /system/app & /system/priv-app
•Zipaligned /system_ext/app & /system_ext/priv-app
• Zipaligned /product/app & /product/priv-app
• Custom TCP congestion algorithm presets
• Heavily debloated w/minimal Google framework
• Kernel level performance optimizations
• Google Pixel 2 dark bootanimation
• Optimized RAM management
• Schedutil tuned CPU governor parameters
• Enabled fast charging (1100 mAh stable)
• GSM support for network unlocked devices
PREREQUISITES:​
An unlocked bootloader ​
A PC or laptop running on Windows 7, 8.1, 10 or 11​
Smartphone must be running Firmware Build No. MH-T6000V1.0.0B010​
The SDK Platform Tools on your Windows computer (link provided below)​
Installation of the proper ADB & Fastboot device drivers on your Windows computer​
The factory supplied, or a quality sufficient, USB-A to USB-C syncing/charging cable​
A reliable internet connection for downloading the required files ​
NOTE: We will not be using a custom recovery for installation of this ROM, but rather the dynamic user space implementation of fastboot mode, formally called FastbootD. This fastboot protocol was first introduced with the release of Android 10, and is primarily utilized for the management of dynamic partitions (devices with a /super partition).
DISCLAIMER:
This guide involves the invasive procedure of flashing the partitions of your device, thus modifying the configuration of the device from its factory stock state. This is always inherently risky to the integrity and operability of your mobile device. By proceeding further, you are assuming sole responsibility for the functionality and physical wellbeing of your mobile phone, thus absolving me of any liability in the event things go badly. This ROM has, however, been tested thoroughly on my own device with no negative issues. Moreover, in the unfortunate event your device becomes bricked or otherwise inoperable by way of a botched adherence to this guide, my firmware restoration guide for this device can restore both soft and hard bricked phones. Moxee m2160 Unbricking Guide
INSTRUCTIONS:
WARNING:
These instructions include steps for initiating a factory data reset, a procedure which will effectively erase all saved user data, app data, app preferences, photos, videos, music, documents and other media files from your smartphone. Make a backup at this point of all data, files and media that you wish to preserve.​
Download the SDK Platform Tools from the link below and extract the contents of the archive to an empty folder on the desktop of your Windows computer​
Download the ROM from the link below and extract the contents of the archive to your platform tools directory created in the previous step​
Because this ROM has been modified to disable DFE force encryption, it is first necessary to format the /userdata partition. With your phone in a powered off state, press the Volume Up & Power keys simultaneously until the Moxee logo appears on your display, at which time you should release the Power key, but continue holding Volume Up until an Android logo and a corresponding No Command notification appears on your phone display. Now quickly press and hold Power, tap Volume Down and then Volume Up to enter stock recovery mode.​
Use the Volume Down key to navigate to the Wipe data/factory reset option, then press Power to select. Confirm this selection on the next screen to initiate the factory data reset.​
Once the factory reset is complete, navigate to the option to Enter Fastboot, then press Power to select. Your phone should now boot to FastbootD mode.​
In the platform tools folder created in the first step, click on cmd-here.exe, then right click and opt to run it as an administrator. A command window will be launched. Now connect your Moxee m2160 to your Windows computer using a sufficient USB-A to USB-C data syncing/charging cable.​
In order to verify proper fastboot communication between your phone and PC, execute the following command:
Code:
fastboot devices
If properly connected, the command window will yield an alphanumeric value consistent with your mobile phone serial number.​
Execute the following commands once a proper fastboot connection has been verified. Note, the user may copy these commands and paste the full text to the fastboot command window for systematic execution:​
Code:
fastboot flash boot boot.img
fastboot flash vbmeta vbmeta.patched.img
fastboot flash vbmeta_system vbmeta_system.patched.img
fastboot flash vbmetabak vbmetabak.patched.img
fastboot flash vbmeta_systembak vbmeta_systembak.patched.img
fastboot erase super
fastboot flash super super_rw.img
fastboot erase metadata
fastboot erase cache
fastboot erase DDR
fastboot erase modemst1
fastboot erase modemst2
fastboot reboot
** Please note that the super_rw.img file is large in size. Fastboot may initially give a header magic notification error. However, the super_rw.img will then be allocated into a number of smaller sparsechunk files, which will subsequently be flashed to your device one at a time, until complete. Just remain patient during this process. This can take five minutes or more, but the process will not require any user action.​
Upon first reboot following installation, and after completing initial device setup, open your app drawer and search for the Magisk app or its stub placeholder. Open Magisk, grant any requested permissions, and follow any prompts by Magisk to update the version or complete setting up the root environment. If you do not see the Magisk app or stub, download the Magisk v26.1 APK from the link provided below and install the app on your phone. Be sure to then open Magisk and follow all prompts.​
DOWNLOADS:
• SDK Platform Tools r34.0.3
• Modified Stock ROM Package
• Official Magisk Releases / GitHub Repo
BUGS:
Please report any bugs or instabilities you may encounter using this modified stock ROM. Those who know how to submit an official bug report are urged to do so. Otherwise, please give a concise and detailed description of the issue, including photos or screenshots if possible. I will work diligently to patch any reported bugs or instabilities.Moxee m2160 Firmware Restoration & Unbricking Guide​
Instructions were great and I had no problems following them. I did have an error when I first entered the command "fastboot erase DDR" but only because I did not capitalize DDR. My only issue is I cannot get past the phone set up when first booting because it says there is an update and can not pass verification and there is no option to skip. And in my case I don't have a computer still so cannot use qfil to return to full stock to update. Any suggestions?
scottfan81 said:
Instructions were great and I had no problems following them. I did have an error when I first entered the command "fastboot erase DDR" but only because I did not capitalize DDR. My only issue is I cannot get past the phone set up when first booting because it says there is an update and can not pass verification and there is no option to skip. And in my case I don't have a computer still so cannot use qfil to return to full stock to update. Any suggestions?
Click to expand...
Click to collapse
Okay. At the time I completed modifications on the ROM, the latest OTA had not yet rolled out. What I'll do is add another mod to kill the OTA service entirely. That should prevent any issues like you're facing. I'll expedite this task and will let you know just as soon as I've made the fix and changed out the ROM file with the new one. Thanks for your feedback. By the way you won't have to repeat the process, but will only need to flash the super_rw.img file.
Update: I have disabled system updates and OTA notifications. Proved trickier than I thought, since system updates on Android Go Edition are governed by Google Play Services. I had to decompile the Google Services apk, manually disable the individual system update service and listeners, then recompile and reinstall the Google Services core app. I am presently uploading the new super_rw.img.
One thing that should work for you in the meantime, while I get these new files uploaded, is to perform another factory data reset. During initial boot and setup, opt to complete setup offline, without connecting to WiFi or a mobile data network. Accordingly, your device will not be able to check for pending system updates and you should, therefore, be able to complete setup.
Viva La Android said:
Okay. At the time I completed modifications on the ROM, the latest OTA had not yet rolled out. What I'll do is add another mod to kill the OTA service entirely. That should prevent any issues like you're facing. I'll expedite this task and will let you know just as soon as I've made the fix and changed out the ROM file with the new one. Thanks for your feedback. By the way you won't have to repeat the process, but will only need to flash the super_rw.img file.
Click to expand...
Click to collapse
That would be awesome. I really appreciate your help.
scottfan81 said:
That would be awesome. I really appreciate your help.
Click to expand...
Click to collapse
The files should be finished uploading within the next 15 minutes or so. I will then update the download link and will inform you here when that's done.
@scottfan81, the latest files are uploaded and the download link has been updated accordingly.
Viva La Android said:
@scottfan81, the latest files are uploaded and the download link has been updated accordingly.
Click to expand...
Click to collapse
That's great! I just got done with my dinner and going to download it now. I will let you know how it goes. And I did see that I only need to flash the super_rw.img file. So I should know shortly.
scottfan81 said:
That's great! I just got done with my dinner and going to download it now. I will let you know how it goes. And I did see that I only need to flash the super_rw.img file. So I should know shortly.
Click to expand...
Click to collapse
Do a factory reset beforehand. Then flash the super_rw.img
@Viva La Android
I haven't had any luck since my last post. Before I posted about the verification issue I had when setting up my phone I made sure I double checked that I did not have the option to skip the update as you suggested. That was not an option for some reason and that is when I came here. I have followed your steps with the new super.rw.img you updated but I am worse off than I was before. Now I cannot do anything as the phone is not recognizing any network or available WiFi connections. I have tried a factory reset and started over from your first step with no success. I should also include that since flashing the updated super.rw.img file, when the phone first boots the screen quickly flashes black and blue for about 10 seconds before finally starting the set up process then I get 2 error messages. The first being "system UI isn't responding" and second "Android setup keeps stopping" After all of that the setup starts and that's as far as I can go because I can't connect to anything. Trying to give you as many details I can think of. Before the screen flashing when powering on the phone, the boot animation just function properly. Only between the boot animation and setup process do I experience the rapid black and blue screen for roughly 10-15 seconds. I am including some screenshots of the error messages and setup screens showing no connections available. I almost forgot. I also tried manually adding my network and scan qr code with no success.
Unfortunately I have physically damaged my device beyond any hope of restoring it, so I won't be able to support this device any longer -- until & unless I can get a replacement display. But before my device went kaplut, I did test this ROM and had no issues. I wish I could be more help.
I would recommend performing all steps over again from the top -- formatting /userdata before doing anything. Have you tried by completing all the steps over?