Related
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
CHANGELOG for 3.0.0-0:
-Completely new theme - Much more modern and much nicer looking (by z31s1g)
-True Terminal Emulator - Includes arrow keys, tab and tab completion, etc. (by _that)
-Language translation - It won’t be perfect and especially some languages that require large font files like Chinese & Japanese won’t be availble on most devices. Also some languages may only be partially translated at this time. Feel free to submit more translations to OmniROM’s Gerrit. (mostly by Dees_Troy)
-Flashing of sparse images - On select devices you will be able to flash some parts of factory images via the TWRP GUI (by HashBang173)
-Adopted storage support for select devices - TWRP can now decrypt adopted storage partitions from Marshmallow
-Reworked graphics to bring us more up to date with AOSP - includes support for adf and drm graphics (by Dees_Troy)
-SuperSU prompt will no longer display if a Marshmallow ROM is installed
-Update exfat, exfat fuse, dosfstools (by mdmower)
-Update AOSP base to 6.0
-A huge laundry list of other minor fixes and tweaks
WARNING: This is our first release in a long time. We have a lot of new and somewhat aggressive changes in this new release. The changes to the graphics back-end may cause some devices to not boot up properly or have other display-related issues. If you are not in a position to reflash an older build of TWRP, then wait until you are or at least wait until others have tried the new version for your specific device. You don’t want to end up with a non-working recovery and have to wait several hours or days to get to a computer to be able to fix it.
Notes for themers: In addition to the udpated theme, we have introduced a theme version variable to the TWRP theme system. If the theme version does not match the version that TWRP expects, TWRP will reject the custom theme and load its stock theme. This change will ensure that people who update TWRP without updating their theme will still have a workable recovery. We have removed libjpeg support. The stock theme was only using a jpeg image for the splash / curtain. This change means that any custom themes will no longer be able to use jpeg images. It also means that tools used to repack recovery images with a different curtain / splash will need to be updated to use the new method.
Version number notes: For a while we’ve been using a 4 digit version number and reserved the 4th digit for device-specific updates. For instance, we find and fix a device-specific issue like decryption of data on Nexus 5, we would release that as a 2.8.7.1. After a while, some people would start asking where 2.8.7.1 was for other devices. So, going forward we have decided to change the numbering scheme to 3.0.0-2, etc. Our hope is that this version numbering scheme will more clearly identify that the 4th digit does not indicate a version change for the code base.
We need your help! The bulk of TWRP work is done by 3 people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance!
CHANGELOG for 2.8.7.0:
-Initial ground work for software drawn keyboard (_that)
-Fix handling of wiping internal storage on datamedia devices (xuefer)
-Allow DataManager to set and read values from the system properties (xuefer)
-Fix crash when taking screenshots on arm64 devices (xuefer)
-Fix error message after an ORS script completes (Dees_Troy)
-Fix crashes / error when creating encrypted backups (_that, Dees_Troy)
-Add system read only option – more details below (Dees_Troy)
-Add resize2fs and GUI option to run resize2fs (Dees_Troy)
-Fix crash loop caused by empty lines in AOSP recovery command file (_that)
-Prevent duplicate page overlays such as multiple lock screens (mdmower)
Note: As always, be sure your custom theme is up to date (or remove your custom theme) before updating TWRP.
System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
resize2fs feature: On some devices like the Nexus 6, the factory images include a userdata image that is the proper size only for the 32GB units. If you flash the factory image to a 64GB Nexus 6, the data partition will appear as if it only has the free space of a 32GB device. Using the resize2fs option, TWRP can resize your data partition to take up the full space available. The resize2fs may also be useful to resize system partitions on devices where custom ROM system images don’t take up the full partition space. Lastly, resize2fs may be useful in some cases to reserve the proper space at the end of a data partition for a full disk encryption key, should your partition be formatted incorrectly for some reason.
This new version also marks our first set of full builds using our new jenkins build server. You can track the progress of builds at https://jenkins.twrp.me and we have taken additional steps to make it easier for device maintainers to step up and submit patches to our gerrit server at https://gerrit.twrp.me to help us keep devices up to date and working.
DOWNLOAD:
You can find more information and download links on our NEW website! NOTE that the 2.8.6.0 version is ONLY available on our new site and is not available on our other, older mirrors!
BUGS:
If you have found a bug, please consider posting it to our github issues log. It's pretty much impossible for us to keep up with the more than 40 threads that we have for the devices that we "directly" support. If you have a significant problem that cannot be answered in this thread, your best bet is to PM Dees_Troy directly, contact us via our website, or find us in our IRC channel below. If you see someone that's struggling, feel free to point it out to us. We need your help to help us keep track of all of our devices! Thanks!
SUPPORT:
Live support is available via #twrp on Freenode with your IRC client or just click this link.
XDA:DevDB Information
TWRP Recovery, Tool/Utility for the Sony Xperia Z3 Compact
Contributors
someone755
Version Information
Status: Stable
Stable Release Date: 2015-08-18
Created 2015-08-18
Last Updated 2016-02-17
Device page on the TWRP website:
Mirror 1
There is no Mirror 2.
Due to the way Sony devices function, you will need to have an unlocked bootloader.
Your options, as far as ROMs go, are the following:
Any ROM with this commit
OR just use the new bootloader (with a proper recovery partition)
All credit goes to the TWRP team. I just annoyed the fools until they built the recovery.
Awesome! Very glad to see this.
After flashing through fastboot, its impossible for me to boot into recovery, my phone stays stuck on the Sony screen with the pink/orange led.
Running resurrection remix and m5 kernel, theme has been updated for 2.8.7, previously was on 2.6.0
Can this be install on LB?
rich2007 said:
Can this be install on LB?
Click to expand...
Click to collapse
it should work with andropluskernel, not with stock
omnomnomkimiiee said:
After flashing through fastboot, its impossible for me to boot into recovery, my phone stays stuck on the Sony screen with the pink/orange led.
Running resurrection remix and m5 kernel, theme has been updated for 2.8.7, previously was on 2.6.0
Click to expand...
Click to collapse
Works fine here. Did you check the md5 before installing? Does it work without the theme?
rich2007 said:
Can this be install on LB?
Click to expand...
Click to collapse
You need a custom boot image to boot into it (since our bootloaders don't really support a separate recovery partition, and we rely on a boot.img script to boot into one), which means you'd have to unlock the bootloader.
funiewski said:
it should work with andropluskernel, not with stock
Click to expand...
Click to collapse
On this note, if anyone can provide me with stock boot images, I'll try and keep them up-to-date with the extract_elf_ramdisk utility, so that users on stock may still boot into TWRP if they don't opt for the AndroPlus kernel.
Hello everyone,
Flashed this with "fastboot flash recovery", still getting the cm12.1 recovery.
BL unlocked, USB debugging enabled, CM 12.1 installed.
Anyone have a solution?
Thanks
Edit:
tried the twrp manager, no Z3C here, aswell the dd method, nothing changed.
pityu100 said:
Hello everyone,
Flashed this with "fastboot flash recovery", still getting the cm12.1 recovery.
BL unlocked, USB debugging enabled, CM 12.1 installed.
Anyone have a solution?
Thanks
Edit:
tried the twrp manager, no Z3C here, aswell the dd method, nothing changed.
Click to expand...
Click to collapse
Same here, there is no Z3C in the list on TWRP Manager, and the 'dd' method leaves an unusable recovery (stuck on orange led). I'm happy with official TWRP support, but do you guys even test your stuff before releasing it.....? The steps with TWRP manager app don't even exist (there is no 'advanced' to tap).
Flashed twrp.img as boot: fastboot flash boot twrp.img. -> TWRP starts every time i power on the phone. Flashed CM12.1 from this state, and TWRP got overwrited again with CM12.1 recovery. /sigh
Is the CM kernel counts as "Any custom kernel" ?
pityu100 said:
text
Click to expand...
Click to collapse
Menubalk said:
Same here, there is no Z3C in the list on TWRP Manager, and the 'dd' method leaves an unusable recovery (stuck on orange led). I'm happy with official TWRP support, but do you guys even test your stuff before releasing it.....? The steps with TWRP manager app don't even exist (there is no 'advanced' to tap).
Click to expand...
Click to collapse
Thanks both of you for reporting your issues. Your reports sparked an investigation, and we were able to identify several issues that have thus far been overlooked (for whatever reason).
The "stuff" was tested before it was released, yes, but we're now facing limitations in the form of unmerged patches to the CM device trees. The issues should have been resolved several years ago, but instead they are now wreaking havoc on Sony msm8974 recovery setups. I've gotten some of the elite TWRP and CM people on this, as well as smaller fellow rhine and shinano developers (though Myself5 and oshomun could hardly be classified as small nowadays).
I personally have already uploaded four changes to the CM gerrit (that should have been applied years ago); One of them got denied (though is now being discussed for the near future (possibly as soon as cm-13.0); the result of that discussion is, among others, that the Cyanogen Recovery is now available for download alongside the ROM zip over at https://download.cyanogenmod.org/?device=z3c ), two are still pending any input whatsoever, and the last one was promised a merge, but the device maintainers have gone quiet, at least on the outside.
(If you wish, you can view the patches and their progress at their links: patch1, patch2, patch3, patch4, patch5.)
However, both teams are also having issues with other matters (such as Z3 not building, or adding new features to TWRP), and there is also the fact that school starts around this time of year (which impacts both the younger developers as well as those who already have children).
To conclude, there really isn't a unified guide I can give you to get to TWRP. It works, and you can use it if you have the correct setup. However achieving that setup is not a simple walkthrough away, and it would differ ever so slightly for every person's preferences, not to mention it would be overwritten with each new ROM update.
Such is the state of affairs at this point in time. This may or may not change, but be assured that everything we can do about this, we will do.
EDIT: A quick note that some ROMs may already include fixes for these issues. I don't know which those ROMs could be, so I won't go into listing them, but the possibility exists.
someone755,
thanks for your quick reply and your investigation.
Hope for the best, but time will tell.
Thanks again
Someone, here is a build that actually works, maybe you guys can base on that?: http://forum.xda-developers.com/z3-compact/development/recovery-twrp-2-8-6-0-fota-recovery-t3093537
I'm on Cyanogen 12.1 nightlies with M5 (=Cyanogen-based) kernel btw.
Menubalk said:
Someone, here is a build that actually works, maybe you guys can base on that?: http://forum.xda-developers.com/z3-compact/development/recovery-twrp-2-8-6-0-fota-recovery-t3093537
I'm on Cyanogen 12.1 nightlies with M5 (=Cyanogen-based) kernel btw.
Click to expand...
Click to collapse
The thing is that if you flash a cm-12.1 boot image (completely stock, without kernel or ramdisk modifications that M5 or Kernel12 perform), it won't work. It works with some setups, but not with others, and is, for some reason, very specific -- to get rid of these errors, CyanogenMod would have to (at the very least) accept my changes.
If you feel like you have to try this for yourself, here's a link to the boot image: https://www.androidfilehost.com/?fid=24052804347797955 Getting out of the mess created once you flash this can be a pickle though, so unless you have a boot image on hand with which you know TWRP works, do not flash the file I linked.
I've had somebody say it started working for him after flashing r_02 of Kernel12, though sadly I'm not very sure that's a permanent solution (it is, however, a working temporary one).
Unfortunately the man who was supposed to review the changes is on leave from development, so waiting is the only option available right now (unless we come up with a zip file to flash after each nightly install, but that would only increase the chaos of this already-confusing situation).
someone755 said:
The thing is that if you flash a cm-12.1 boot image (completely stock, without kernel or ramdisk modifications that M5 or Kernel12 perform), it won't work. It works with some setups, but not with others, and is, for some reason, very specific -- to get rid of these errors, CyanogenMod would have to (at the very least) accept my changes.
If you feel like you have to try this for yourself, here's a link to the boot image: https://www.androidfilehost.com/?fid=24052804347797955 Getting out of the mess created once you flash this can be a pickle though, so unless you have a boot image on hand with which you know TWRP works, do not flash the file I linked.
I've had somebody say it started working for him after flashing r_02 of Kernel12, though sadly I'm not very sure that's a permanent solution (it is, however, a working temporary one).
Unfortunately the man who was supposed to review the changes is on leave from development, so waiting is the only option available right now (unless we come up with a zip file to flash after each nightly install, but that would only increase the chaos of this already-confusing situation).
Click to expand...
Click to collapse
Had no issues with my 2.8.7.0 twrp built into my ROMs boot.img been working with no issues so far
Sent from my Z3 Compact using Tapatalk
jenkins-84 said:
Had no issues with my 2.8.7.0 twrp built into my ROMs boot.img been working with no issues so far
Sent from my Z3 Compact using Tapatalk
Click to expand...
Click to collapse
The goal of FOTA recoveries was to let the user boot into a recovery regardless of what recovery is in the boot image. If you flash a CM nightly over your setup, you won't be able to get to TWRP again unless you perform various modifications to the CM boot image.
Packing recovery inside boot is what's causing all these issues in the first place, so doing what you suggest would be a step forward, but two steps back as well.
someone755 said:
The goal of FOTA recoveries was to let the user boot into a recovery regardless of what recovery is in the boot image. If you flash a CM nightly over your setup, you won't be able to get to TWRP again unless you perform various modifications to the CM boot image.
Packing recovery inside boot is what's causing all these issues in the first place, so doing what you suggest would be a step forward, but two steps back as well.
Click to expand...
Click to collapse
Yeah maybe but I don't care to much for CM based ROMs was for people using slimlp based mainly
Sent from my Z3 Compact using Tapatalk
jenkins-84 said:
Yeah maybe but I don't care to much for CM based ROMs was for people using slimlp based mainly
Sent from my Z3 Compact using Tapatalk
Click to expand...
Click to collapse
That's all fine and dandy until you realize most people are sticking with CM (for some unexplainable reason). Other ROM gerrits are much more likely to have already merged the needed changes (and are much more lenient and open when it comes to accepting new changes in general, and all this is the only reason this waiting game is now on).
someone755 said:
That's all fine and dandy until you realize most people are sticking with CM (for some unexplainable reason). Other ROM gerrits are much more likely to have already merged the needed changes (and are much more lenient and open when it comes to accepting new changes in general, and all this is the only reason this waiting game is now on).
Click to expand...
Click to collapse
Yeah but I don't wait on slim or use its device trees etc I build for my own and use commits I want, I don't really care what people use or do. I build ROMs for myself and a friend. I just happened to share a ROM that I don't care if people use or not. If I'm happy with what I build and use then that's all I care about
Sent from my Z3 Compact using Tapatalk
jenkins-84 said:
Yeah but I don't wait on slim or use its device trees etc I build for my own and use commits I want, I don't really care what people use or do. I build ROMs for myself and a friend. I just happened to share a ROM that I don't care if people use or not. If I'm happy with what I build and use then that's all I care about
Sent from my Z3 Compact using Tapatalk
Click to expand...
Click to collapse
You do realize TWRP is meant to work for everyone, not just for 'me and my bros'?
On topic:
Someone, that FOTA TWRP I linked does (or at the very least did, I've been on M5 Kernel for a few weeks now) work with a stock Cyanogenmod boot image. Before M5 kernel I could already reach TWRP. I really think it worth a closer look to see what that guy did because it works/worked for some reason..
My full sequence (the first time anyway):
Unlock Bootloader
Unpack boot.img from Cyanogenmod nightly zip
Flash boot.img in fastboot
Boot to Cyanogenrecovery
Wipe
Flash Cyanogenmod in recovery
Boot Cyanogenmod, Setup Wizard yadda yadda
Shut down and go to fastboot
Flash FOTA TWRP from said link
Test FOTA TWRP, Be happy
----Few days later----
Flash M5 through FOTA TWRP
Multirom allows the use of the external sd card to have several rom's "installed" and swap between them via a menu at bootup (similar to the grub menu under linux). It uses a custom version of twrp which also allows normal backup and restore of the rom's in question. @petrov.0 @Unjustified Dev and anyone else qualified.....would you consider reviewing this as a possible future project? With the ability of the idol3 to use large 128gb sd cards it would make a great tool for rom testing.
https://github.com/Tasssadar/multirom/wiki/Porting-MultiROM
It would appear we have the necessary prerequisites:
Prerequisites
Android 4.1+ tree
TWRP ported to your device.
Kernel sources
@famewolf Now that my device is on the way I want to go ahead and answer this question. It's possible although we face a challenge as the kexec tools that tasssadar uses lack support for arm64. Me and Steel01 on xda will be working on getting upstream tools working for arm64 in Android. It requires we backport upstream kernel patches as well. If we can succeed, I see no reason why we couldn't get kexec hardboot working. The issue we face with the idol 3 is that there's no stock kernel made for all variants that works and has source available. So that means you'll have to have a custom ROM as primary and stock as secondary since the primary ROM needs kexec hardboot to chainload the secondary ROMs kernel.
Exciting!
Unjustified Dev said:
@famewolf Now that my device is on the way I want to go ahead and answer this question. It's possible although we face a challenge as the kexec tools that tasssadar uses lack support for arm64. Me and Steel01 on xda will be working on getting upstream tools working for arm64 in Android. It requires we backport upstream kernel patches as well. If we can succeed, I see no reason why we couldn't get kexec hardboot working. The issue we face with the idol 3 is that there's no stock kernel made for all variants that works and has source available. So that means you'll have to have a custom ROM as primary and stock as secondary since the primary ROM needs kexec hardboot to chainload the secondary ROMs kernel.
Click to expand...
Click to collapse
Exactly which Kernels are you and @petrov.0 using?
Enhanced twrp for op3 and op3t
Download from official server:
Download for oxygenos and other non-treble ROMs: https://glassrom.pw/op3_recovery.img
Download for treble ROMs: https://glassrom.pw/op3_recovery-treble.img
Download from CDN:
Download for oxygenos and other non-treble ROMs: https://cdn.glassrom.pw/op3_recovery.img
Download for treble ROMs: https://cdn.glassrom.pw/op3_recovery-treble.img
Unofficial mirrors:
Hosted by @Sytis https://storage.ceres-sys.de/glassrom
Don't ask these questions. Seriously:
Features: none. It's a recovery. It should be as simple as possible because you rely on this stuff to recover your device in case something goes wrong
Seriously. Were you expecting features from a custom recovery?
Screenshots: it looks like TWRP
Important. There is a blank option and a system_root option in the mounts section. These are only for compatibility with scripts. Do not try to tick them yourself
Some scripts may throw a "failed to umount /system_root" message. This is fine
Important: why do some ROMs refuse to flash?
Some ROMs like oxygenos and glassrom use a feature called "downgrade attack prevention". If TWRP's build date is higher than the build date of the ROM the installation script assumes a downgrade attack is happening and the flashing fails
System nandroid restore fails:
You are not supposed to be restoring file-based backups of the system partition on a device with dm-verity in the first place. Backup and restore system image backups.
Glassrom users: if this is your first time flashing glassrom remember that the current enhanced twrp will always have a build date higher than the current glassrom build. In other words you can only flash a newer glassrom build as long as your enhanced twrp build is older or in other words:
Switching to glassrom: use official twrp, flash glassrom and then flash enhanced TWRP to enforce downgrade attack prevention
Updating glassrom: no need to switch to official. Always update glassrom before you update enhanced twrp
This was intentionally done to prevent downgrade attacks on glassrom. Using enhanced twrp with glassrom is recommended
This TWRP addresses a number of issues that have been plaguing the op3:
Uses a backported F2FS driver (5.1-rc1-3.18) that fixes an issue where TWRP would get stuck on the TWRP splash screen for a long time if the user was using F2FS
Uses an upstream kernel that was taken from lineage's common kernel https://github.com/LineageOS/android_kernel_qcom_msm8996
Added all crypto footer code back to resolve all encryption issues
Improved detection of device variant. Recovery now validly detects op3 and op3t
A full selinux policy so that files do not get labelled incorrectly. This resolves a bunch of issues like "device doesn't boot after restoring nandroid"
Built against full lineage source. No minimal manifest or any other nonsense
Upstreamed sdfat driver for better suppport for USB-OTG drives
No prebuilt kernels. Uses a fully source built kernel
Kernel built with a compatible GCC 8. No weird compiler optimisation
Ext4 is the default filesystem instead of f2fs
Current issues: even if the source code is out building TWRP against lineage is not something a beginner can do. If somebody is willing to contribute build documentation they are more than welcome
XDA:DevDB Information
Anupritaisno1's enhanced twrp builds, Tool/Utility for the OnePlus 3
Contributors
anupritaisno1, anupritaisno1, dianlujitao
Source Code: https://github.com/GlassROM-devices
https://bitbucket.org/anupritaisno1/aarch64-linux-gnu
Version Information
Status: Stable
Current Stable Version: 3.3.0
Stable Release Date: 2019-05-01
Created 2019-05-03
Last Updated 2019-05-02
A request to moderators:
People often ask "screenshots" and "features" while this really doesn't make much sense in the context of a recovery. It's a recovery
Please delete such posts to keep the thread clean
Reserved
Feedback:
update-scripts that use run_program("/sbin/busybox) doesn't work as of the latest TWRP builds.
aboodyaiman said:
Feedback:
update-scripts that use run_program("/sbin/busybox) doesn't work as of the latest TWRP builds.
Click to expand...
Click to collapse
Busybox was removed. I've updated my flashable zips to use run_program("/sbin/mount", "/system"); instead.
Replacing 'busybox' with 'toybox' should work too.
Dirk said:
Busybox was removed. I've updated my flashable zips to use run_program("/sbin/mount", "/system"); instead.
Replacing 'busybox' with 'toybox' should work too.
Click to expand...
Click to collapse
Have you tried this*? I'm waiting feedback :silly:
I'm not in a good time for messing around..
*i mean the recovery as general
aboodyaiman said:
Feedback:
update-scripts that use run_program("/sbin/busybox) doesn't work as of the latest TWRP builds.
Click to expand...
Click to collapse
Busybox is pretty terrible and most of it's executables aren't even compliant to standards
Please update your scripts to use toybox or ship the actual statically linked binaries
Dirk said:
Busybox was removed. I've updated my flashable zips to use run_program("/sbin/mount", "/system"); instead.
Replacing 'busybox' with 'toybox' should work too.
Click to expand...
Click to collapse
You should specify the "-o rw,remount" flag otherwise if mount system partition read-only is ticked there's a high chance system is mounted read-only and the script won't actually touch the system partition. This can be achieved by using a shell script instead of run_program()
Your command can also fail with "cannot find /system in the fstab". Instead of calling mount that way you should use this edify command and then call mount with run_program() to make sure it doesn't fail
Code:
mount(fs_type, partition_type, name, mount_point)
Please see https://source.android.com/devices/tech/ota/nonab/inside_packages
Toybox uses a slightly different mount command so merely replacing all instances of busybox with toybox will not work
anupritaisno1 said:
Busybox is pretty terrible and most of it's executables aren't even compliant to standards
Click to expand...
Click to collapse
IMHO bb is much more sophisticated then tb. If compiled with long options enabled bb is more posix compliant then any other multicall binary I know of.
The original decission to replace bb by tb by google was made because of license politics (bb: gnu copy left; tb: apache) - technically bb is superior to tb, for the amount of implememted commands as well as the posix compliance of the implemented commands (if configured correctly). I.e. parts of dns and resolver libs in tb are broken from the beginning of tb used in android (though this doesn't matter in recovery only use). fgrep/egrep are another broken/non-posix-compliant topic, which is solved by adding standalone binaries.
The claim you've made is at least questionable, and since you are publishing your sources (aka complying to gpl), the main reason for not using bb is not true for your twrp builds.
You may consider to put in bb additionally. For los integration, I've made a bb setup not overriding any tb links and installing bb as well as it's links to /system/xbin. With nearly no effort the installation target could be changed to i.e. /xbin or /bb/bin. If the installation dir is added in the path after the path to tb, you'll ship a recovery not only compatible with latest pie sources, but also with backward compatibility for flashable zips relying on bb.
https://github.com/nvertigo/android_external_busybox/tree/nlos-16.0
nvertigo67 said:
IMHO bb is much more sophisticated then tb. If compiled with long options enabled bb is more posix compliant then any other multicall binary I know of.
The original decission to replace bb by tb by google was made because of license politics (bb: gnu copy left; tb: apache) - technically bb is superior to tb, for the amount of implememted commands as well as the posix compliance of the implemented commands (if configured correctly). I.e. parts of dns and resolver libs in tb are broken from the beginning of tb used in android (though this doesn't matter in recovery only use). fgrep/egrep are another broken/non-posix-compliant topic, which is solved by adding standalone binaries.
The claim you've made is at least questionable, and since you are publishing your sources (aka complying to gpl), the main reason for not using bb is not true for your twrp builds.
You may consider to put in bb additionally. For los integration, I've made a bb setup not overriding any tb links and installing bb as well as it's links to /system/xbin. With nearly no effort the installation target could be changed to i.e. /xbin or /bb/bin. If the installation dir is added in the path after the path to tb, you'll ship a recovery not only compatible with latest pie sources, but also with backward compatibility for flashable zips relying on bb.
https://github.com/nvertigo/android_external_busybox/tree/nlos-16.0
Click to expand...
Click to collapse
Thanks. I guess I was wrong about busybox
I'm still not considering shipping busybox. Whenever I've tried it something broke so I'll just be sticking with toybox on that part
What I might be able to do is make a zip that copies busybox to /sbin/busybox and since it's just copying in ram there shouldn't be much of a problem. Users can flash this zip as a way to have backward compatibility with older zips. That sounds like a much better option honestly as then the fix is not just tied to my recovery but can be used on every recovery that doesn't have busybox on the op3
Edit: I also do not think shipping your busybox is a very good idea. You're compiling busybox with this
-Wno-error=implicit-function-declaration -Wno-implicit-function-declaration
Click to expand...
Click to collapse
I don't even know why this is a compiler warning. This should be an error but if you're shipping busybox with that warning disabled instead of fixing it that's just asking for trouble
anupritaisno1 said:
What I might be able to do is make a zip that copies busybox to /sbin/busybox and since it's just copying in ram there shouldn't be much of a problem.
Click to expand...
Click to collapse
...and on every second page of this thread, you'll be asked, if flashing bb is necessary on each update. Then you'll need to answer every time: "no, you need to flash it prior to each flashing of a bb needing zip."
If you just say bb is droped upstream and you want to keep your twrp clean.
Anyway: I've fixed the static build target.
anupritaisno1 said:
Edit: I also do not think shipping your busybox is a very good idea. You're compiling busybox with this
Click to expand...
Click to collapse
Thanx for the heads up - you are absolutly right here! (This was on my todo list more then 2 years ago, then I fogot to do it... I don't like people pointing me to my old and forgotten todos... )
https://github.com/nvertigo/android_external_busybox/commit/f512d6cbb4181970b47383a6efe0c01f27a0d978
nvertigo67 said:
...and on every second page of this thread, you'll be asked, if flashing bb is necessary on each update. Then you'll need to answer every time: "no, you need to flash it prior to each flashing of a bb needing zip."
If you just say bb is droped upstream and you want to keep your twrp clean.
Anyway: I've fixed the static build target.
Thanx for the heads up - you are absolutly right here! (This was on my todo list more then 2 years ago, then I fogot to do it... I don't like people pointing me to my old and forgotten todos... )
https://github.com/nvertigo/android_external_busybox/commit/f512d6cbb4181970b47383a6efe0c01f27a0d978
Click to expand...
Click to collapse
I haven't really checked the code but I'm not that sure about this part
Shouldn't it be like
Code:
#ifndef _GNU_SOURCE
#define _GNU_SOURCE
Idk just sounds more correct that we don't want a redefinition here
Is there any need for a manual mount of 'fakecache' like in Enhanced TWRP of OP2 ?
I hope not...
Thanks for the development !
gps3dx said:
Is there any need for a manual mount of 'fakecache' like in Enhanced TWRP of OP2 ?
I hope not...
Thanks for the development !
Click to expand...
Click to collapse
The entire fakecache experiment was me trying to port treble to the op2
That obviously failed and I'm in the process of removing that hack even from the op2
It's not there on this TWRP. That's for sure
F2FS 5.2-rc1-3.18 is out
The update will first arrive on glassrom and then on enhanced TWRP
anupritaisno1 said:
F2FS 5.2-rc1-3.18 is out
The update will first arrive on glassrom and then on enhanced TWRP
Click to expand...
Click to collapse
Glassrom is out but I've sadly not received any feedback from the twrp testers yet
The new release might be delayed and I'm also busy working on op2
It will definitely come in 1-2 days
Glad you made this twrp @anupritaisno1.
Working great here and happy to see all issues I had with other versions (some warnings on terminal, time issues etc...) are gone!
Keep up the good work
@anupritaisno1
Any chance your TWRP is not compatible with PIE ? ( i.e either that PIE is not supported or PIE is NOT the highest SDK supported )
I ask since many users across OP3 & 3T forum complained about "BSoDwWL" (Black Screen of Death with White Led ) issue that appear randomly ( not during recovery, but in android ) and freeze the device for ~15sec which ends in systemUI reboot.
I'm not sure, but around the week I updated myy recovery to your TWRP, I started to suffer for that issue - which is partially in accordance with this report - i.e that SOME TWRP is responsible
please don't get me wrong... as it might be TWRP original code fault - not something directly related to your own wonderful work here.
I wonder if you encountered this issue as well ?
Does TWRP 3.3.x is already Q compatible ? what's the LAST twrp version that its higher SDK support is PIE (3.2.x / 3.1.x ) ?
gps3dx said:
@anupritaisno1
Any chance your TWRP is not compatible with PIE ? ( i.e either that PIE is not supported or PIE is NOT the highest SDK supported )
I ask since many users across OP3 & 3T forum complained about "BSoDwWL" (Black Screen of Death with White Led ) issue that appear randomly ( not during recovery, but in android ) and freeze the device for ~15sec which ends in systemUI reboot.
I'm not sure, but around the week I updated myy recovery to your TWRP, I started to suffer for that issue - which is partially in accordance with this report - i.e that SOME TWRP is responsible
please don't get me wrong... as it might be TWRP original code fault - not something directly related to your own wonderful work here.
I wonder if you encountered this issue as well ?
Does TWRP 3.3.x is already Q compatible ? what's the LAST twrp version that its higher SDK support is PIE (3.2.x / 3.1.x ) ?
Click to expand...
Click to collapse
Please get me a copy of /sys/fs/pstore/console-ramoops-0 on the next boot after the crash
gps3dx said:
@anupritaisno1
Any chance your TWRP is not compatible with PIE ? ( i.e either that PIE is not supported or PIE is NOT the highest SDK supported )
I ask since many users across OP3 & 3T forum complained about "BSoDwWL" (Black Screen of Death with White Led ) issue that appear randomly ( not during recovery, but in android ) and freeze the device for ~15sec which ends in systemUI reboot.
I'm not sure, but around the week I updated myy recovery to your TWRP, I started to suffer for that issue - which is partially in accordance with this report - i.e that SOME TWRP is responsible
please don't get me wrong... as it might be TWRP original code fault - not something directly related to your own wonderful work here.
I wonder if you encountered this issue as well ?
Does TWRP 3.3.x is already Q compatible ? what's the LAST twrp version that its higher SDK support is PIE (3.2.x / 3.1.x ) ?
Click to expand...
Click to collapse
Hi I checked this myself
There seems to be absolutely no difference between drivers from 5.0.8 and 9.0.2
It feels as if oneplus simply took the drivers from 5.0.8 and smashed them onto 9.0.2 so I have no idea what crashes you're observing. Please submit logs
Here is PitchBlack recovery For the Alcatel Tetra.
I am not responsible for anything you choose to do with it,
Thanks go to my Test group over on telegram.
@clcombs262
@PizzaG
This is an Unofficial Port
so any bug reports need be listed here.
credit for orig. source go's to the PBRP team
For more info on sources Google is your friend.
I am open to donations, we are trying to buy a new pc.
Recovery Image and Flashable zip with the extra's
AIO toolkit
ROMS all RECOVERIES Everything is now found here:
https://t.me/Android_General_Chat
ChangeLog:
current time is =3:38PM CDT
date is=July 10 2019
This is now the Final-Release candidate
Fixed Bug in adb
fixed a bug that wouldn't allow flashing of the GSI system images
Now everything is reported as working
Enjoy
Note: interestingly I had the same bugs in two different recoveries
Deleted
Read the pm
Deleted
Will this work on the latest phone update? Still on 8.1, but as soon as it hit WiFi it updated to 8MA6UA60. Phone is cheap enough now to maybe break trying.. lol. And these GSI images currently work or is this trial and error? I was shocked by this phones performance on stock for it's price.. I just want to see it's full potential.
Edit: have not gotten this to be able to flash and stick. However you need the fastboot fix on the twrp forum (p23) to even attempt it on ua60.
You'll have to edit the command in the readme to match the updated kernel file as it got updated, but the script rundown did not.
stayboogy [ROM] AOSP 12L (12.1.0_r3, SPA2 5G) for Pixel 5 [redfin]
stayboogy AOSP 12L (12.1.0_r3, SPA2 5G) Redfin sources: base repo: https://android.googlesource.com/platform/manifest/+/refs/heads/android-12.1.0_r3/default.xml my work: https://github.com/stayboogy/stayboogy_Redfin this rom...
forum.xda-developers.com
1 Bug has been found so far:
Camera app will disappear from the app drawer, but it is still available from "double click power button" accessibility settings. It works out of the box if it has disappeared, but if you change the button settings it won't work any longer or be visible.
I'm working on tracking the fix.
Everything else works just as it should.
I have now uploaded a boot+recovery.img which can be used to boot into the Google Factory Recovery from adb using "adb reboot recovery"
--this is mainly useful to wipe userdata if you need to root after install, which makes rooting easier and no longer has to be done at install time since data has to be wiped.
--this recovery will be edited to install any zip without verification so that any update.zip can be applied such as open-gapps-installer.zips
I have also uploaded a root+boot.img which is patched with latest magisk already
I have also uploaded a root+boot+recovery.img which has both magisk root and Google Factory Recovery built into it.
THIS ROM ONLY AND IT'S VARIOUS BUILDS
These files are here:
stayboogy_Pixel5-Android12-AOSP/Build-1/imgs at main · stayboogy/stayboogy_Pixel5-Android12-AOSP
Stayboogy Pixel 5 AOSP 12.0.0.r3 [straight from https://android.googlesource.com/] - stayboogy_Pixel5-Android12-AOSP/Build-1/imgs at main · stayboogy/stayboogy_Pixel5-Android12-AOSP
github.com
Direct Links:
stayboogy_Pixel5-Android12-AOSP/direct-links at main · stayboogy/stayboogy_Pixel5-Android12-AOSP
Stayboogy Pixel 5 AOSP 12.0.0.r3 [straight from https://android.googlesource.com/] - stayboogy_Pixel5-Android12-AOSP/direct-links at main · stayboogy/stayboogy_Pixel5-Android12-AOSP
github.com
Direct Links have been added to everything.
I've cooked up a build of TWRP for this ROM, but I haven't had time to test it or upload it.
seriously i work heavily to i have 6 children but if u need another person to test for you im definitely down right now im trying to load corvos os or havoc just for playing
I appreciate the offer man. The only issue right now is I have very poor internet where I'm staying right now. My upload speeds are s*** so by the time I get something uploaded I've already tested it myself.
Twrp's repo for building the recovery is borked right now so I'm having lots of issues getting an image built to use for my ROM.
I will be having some more rom
releases coming soon though to be tested.
New Build coming as soon as I can get it all uploaded.
Build2 will include signed gapps [no spoofing like with CalyxOS which is terribly insecure in all ways] built inline with the rest of the system since I have yet to get a new twrp build working for 12.0.0+
Build2 will also include factory recovery already in the boot, mainly for wiping the device should you need to as installing zips still fails for some reason.
I also did not add the automotive files to either build as my main goal with these builds is a slim system without a lot of unnecessary fluff.
Other slight modifications coming soon as well.
Because Google is cracking down on distributing signed GApps directly on a device with AOSP Based Roms, you have to manually add your Google Play Store device identifier to Google's whitelist system. I'm not going to do this, and I do not suggest you do either. I have a build with signed GApps built inline with the AOSP system but it continually notifies for being "uncertified" by Google. Again this can be overcome by adding your Google Play Store device identifier to Google's whitelist. Because of this, I am not going to release a build including singed GApps.
I also will not be adding "signature spoofing" to support MicroG, OpenGApps, or any other variations of open source GApps. This is because, regardless what CalyxOS, LineageOS, and others have successfully convinced people of, signature spoofing is NOT SAFE, and it can easily be hijacked regardless of your settings in MicroG to gain unlimited background access to your device. I don't suggest it at all, and is why I don't use LineageOS or CalyxOS, but have opted to build AOSP like I have.
GApps Compatibility
stayboogy_Pixel5-Android12-AOSP/GApps_MagiskModules_direct-links at main · stayboogy/stayboogy_Pixel5-Android12-AOSP
Stayboogy Pixel 5 AOSP 12.0.0.r3 [straight from https://android.googlesource.com/] - stayboogy_Pixel5-Android12-AOSP/GApps_MagiskModules_direct-links at main · stayboogy/stayboogy_Pixel5-Android12-...
github.com
hoping to have the camera bug fixed with the latest build, which is forthcoming, probably tomorrow sometime.
Has anybody installed this yet?? Looks like something straight out of the early Sony Xperia days
thatsupnow said:
Has anybody installed this yet?? Looks like something straight out of the early Sony Xperia days
Click to expand...
Click to collapse
it's straight AOSP, with no customization, as of yet anyway.
Build2 Uploading now!
*Camera Bug Fixed
**New Default Wallpaper
***Factory Recovery Already in boot.img
Build-2 Live, See OP for Links
Added New Info For GApps Compatibility. Several Magisk Modules Options Now.
stayboogy_Pixel5-Android12-AOSP/GApps_MagiskModules_direct-links at main · stayboogy/stayboogy_Pixel5-Android12-AOSP
Stayboogy Pixel 5 AOSP 12.0.0.r3 [straight from https://android.googlesource.com/] - stayboogy_Pixel5-Android12-AOSP/GApps_MagiskModules_direct-links at main · stayboogy/stayboogy_Pixel5-Android12-...
github.com
at 97% complete on a 12.1 build from a new development machine, based on the same code the last OTA was, vanilla though of course.
12.1 coming tonight.
should mean this build will be compatible with the working TWRP image, fingers crossed
I'll have 12.1 uploaded sometime Friday most likely--already built and working just fine, with April OTA firmware too, but still Vanilla AOSP. Currently re-working on twrp for these builds so that we have a working recovery to do whatever we need. And to make upgrading to newer builds simpler.
once I have a working twrp image that is embedded as a stock recovery option into the boot.img, I will start working on bringing features like call recording, theming, etc into the builds. those types of additions are fairly simple.
we also need twrp for better GApps options should you wish to use them. I won't be for daily use, but I intend to make this Vanilla AOSP look much better while still keeping it simple.
and for the record, you can already used xposed and magisk modules to signature spoof to use MicroG, but it will not be baked into my builds at all. I don't support it. I don't really support Google GApps either. I intend to use this vanilla once twrp is working and I get the mods I use regularly added and it looks better. All forthcoming very soon I assure you.
GOT TWRP WORKING!!! (using the working image I posted about in the Guides section 3.6.1_11-0)
Unfortunately, you must wipe your userdata and encryption must be disabled for userdata...
Here's how to have working TWRP for my AOSP ROMs for now, until I have twrp encryption support.
1) root your rom, directions are in OP
2) make sure you are actually rooted with the patched boot.img flashed
3) adb root
4) adb remount
5) adb shell rm /vendor/etc/fstab.sm7250
6) adb push fstab.sm7250 /vendor/etc/
7) Settings-->System-->Reset Options-->Erase All Data (factory reset)
8) after "Erasing" is finished immediately hold the volume down button to get into bootloader
9) fastboot boot twrp.img
10) adb push twrp.img /
11) Advanced Menu-->Install Ramdisk-->choose the twrp.img you just pushed to /
12) Backup your current boot.img only and copy to your internal sdcard and rename from ***.win to ***.img
13) reboot to system and install Magisk
14) patch the boot.img you just backed up
15) reboot to bootloader
16) fastboot flash boot last.boot.img
17) now you have twrp and root for aosp
EDIT: Looks like this may not be permanently working...ugh. This file gets overwritten on reboot for some reason, probably baked into the ramdisk. I'll have it conquered before long I assure you
Should have 12.1 up sometime today/tonight. Call recording, round icons, some hidden settings enabled, various other small changes will be in available with its release.
alright, i've got 12.1 built with gapps minimal built inline, and once your android id is put into Google you will pass play protect
however, device overlays that include lots of the mods I had planned such as call recording which i've successfully patched the dialer app for, just aren't getting copied over because of some issues in the boardconfig from google in aosp source. it took me a while to figure out what was going on, but i'm rebuilding right now.
I'm also working with the Lineage source too at the moment, going to remove signature spoofing support and release a build of it as well. Working on finding the best configuration for everything.