Database Info

Kernal Source Released

The Kernal Source has been released by Razer.
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813

It has been talked about already but not in this section. This is where it belongs and nice job posting direct links to it.
https://forum.xda-developers.com/razer-phone/how-to/source-code-posted-t3719665

MedicStuder said:
Surprised no one else posted in the section with this. The Kernal Source has been released by Razer which means modding can start.
https://www.xda-developers.com/razer-phone-kernel-source-code/
http://www.androidpolice.com/2017/12/15/kernel-source-code-just-released-razer-phone/
https://www.gizchina.com/2017/12/16/razer-releases-kernel-source-files-razer-phone/
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
Click to expand...
Click to collapse
I mentioned it in the factory image thread 5 days ago

Mods, can we pin this in the dev section since it contains the links to the needed source code for development purposes. Seems appropriate to have it pinned in this thread. thanks.

I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)

Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?

MishaalRahman said:
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
Click to expand...
Click to collapse
No way! :victory:
That's the best news I've heard yet
---------- Post added at 04:44 AM ---------- Previous post was at 04:30 AM ----------
jcadduono said:
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Click to expand...
Click to collapse
I'm willing to temporarily sacarfic my device for this. I will message you tomorrow morning and we can give it a shot.

We have lift off! @jcadduono you were right :highfive:
Waiting on you for further instructions on how to proceed.
Even if this leads to no where it sure feels damn good to see the twrp logo.

Everything is going well, we're getting copies of each partition and I'm working on making factory restorable images right now.
I am fairly certain I can even support encryption on this device with no issues.
The device itself actually supports hardware Qualcomm full-disk encryption like most non-Google Qualcomm devices so it's nothing new!
However, the Razer Phone supports HW encrypted SDcards like LG does, so TWRP needs support in the actual crypto code used in the project to work with encryptable sdcards. Maybe Dees_Troy will be up to that task when he gets his phone.
TWRP images will be distributed like so:
- A twrp.img file that you flash to your active boot partition
- A zip file that copies the TWRP ramdisk from your active boot partition into your inactive boot partition, then copies your inactive boot partition to your active boot partition
The zip file will effectively install TWRP and the next time you boot TWRP it will be relying on your ROM's kernel instead of the TWRP kernel.

jcadduono said:
Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
Click to expand...
Click to collapse

@jcadduono Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
P.s I'll take a pop if you want a second test

thread stuck like Chuck for now, hopefully we can get some dev going for this device.

yeahh !!!!!!! wake up dev teams !!

Any information regarding Franco kernel?

[Guide-WIP] How to Root the Pixel 3 XL

I don't have my device yet, but here's what someone with the device can do once you have unlocked your bootloader:
Update: This method will work once MagiskManager is patched to support the P3XL:
https://twitter.com/topjohnwu/status/1052993970303889418
1) Download the latest factory image from here:
https://developers.google.com/android/images#crosshatch
2) Extract the file to your pc somewhere. Inside the archive, there is a boot.img
3) Upload boot.img to /sdcard
4) Install Magisk Manager from the link below. You can use adb install from the command line, or upload to your phone and sideload it with some file manager app (Root explorer for example).
https://github.com/topjohnwu/Magisk/releases/download/manager-v6.0.0/MagiskManager-v6.0.0.apk
5) Open Magisk Manager app and choose install. Select the boot.img file you uploaded in step 3
6) Copy the patched_boot.img file generated from Magisk Manager in step 5 to your pc.
7) Reboot to bootloader (adb reboot bootloader) or Power off the phone completely, and hold volume down while you power it up.
8) fastboot flash boot patched_boot.img
9) Reboot and check to see if you have root in Magisk Manager.
If this does not work or you get into a boot loop or it freezes, simply reboot to bootloader and flash stock boot.img from the factory image.

We need twrp

TheUndertaker21 said:
We need twrp
Click to expand...
Click to collapse
I believe this method would bypass the requirement for twrp. I won't be able to test until I get home tonight but I will try and update later.

Apparently Topjohnwu has confirmed that MagiskManager does not patch the boot image correctly, so this does not work as of yet. Will most likely need a new version of MagiskManager to get this working. I will modify the first post accordingly.
TheUndertaker21 said:
We need twrp
Click to expand...
Click to collapse
No we do not.

Today is the day

From his Twitter. Should be any day now. Excited
https://twitter.com/topjohnwu/status/1053488124389720064?s=19

Welcome to the Magisk family, Pixel 3!
I originally planned to do more changes to Magisk Manager before a new public release, but I think people can't wait to root their shiny new Pixel 3, so here we go!
Up-to-date Documentations
Some subtle details, design choices, developer guides are all added to the documentations!
For most average users though, the most interesting part would be the tutorial: Best Practices for MagiskHide, please take some time and check it out!
Magisk Documentations
Boot Image Header v1
Google updated the boot image header format from v0 to v1 and was first used on the Pixel 3. The new header supports recovery DTBOs, which won't be used on any A/B devices, including Pixel 3 so that isn't the main issue here. The new format stores its version number to an originally unused entry in the header to determine whether the extended header entries is used. However in some freaking devices like Samsung's, they have been using the supposedly "unused" entry as the size of an non-AOSP "extra section" for quite a long time. magiskboot is designed to support extracting these extra sections (because people use Samsung), but with the introduction of header v1, the tool couldn't interpret the image properly, and thus generating invalid boot images.
magiskboot's boot image parsing, unpacking and repacking code was rewritten with C++ to utilize the more powerful language features due to the complexity (because I still need to support freaking PXA format headers used by old Samsung devices...)
MagiskSU Rewrite
Both the daemon and client side of MagiskSU is completely rewritten with improvements and optimizations, for example: simplified `su_info` caches, early ACK between daemon and client to prevent process freezing when denied, sending parsed command-line options instead of full arguments, and many more!
Samsung Defex Patches
A hexpatch for removing Samsung's new KNOX feature: Defex Safeplace was actually already introduced in previous releases, but that solution wasn't ideal since each new kernel release would generate different patterns. A more general patch (which is only a single CPU instruction!) was discovered and included into this new release.
Magisk-Modules-Repo Moderation
If you aren't aware, a team of zealous volunteer moderators were already starting to review new submission manually, being the gate keeper of our beloved Magisk-Modules-Repo. Hopefully this will prevent pointless/spam modules polluting the download section in Magisk Manager!

Thread closed as per OP request.
Thanks
SacredDeviL666
Forum Moderator.

[UNOFFICIAL] Enhanced TWRP

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

How To Guide [OUTDATED - PLEASE USE UNOFFICIAL LINEAGEOS INSTEAD] Installing a GSI on Samsung M12/A12.

I am deleting this guide since M12 will soon recieve an unofficial build of LineageOS 19.1. Don't ask when, as I'm not the lead developer but I helped with it

Update 1: I figured out how to make script run on boot. Instructions revised. If you followed earlier check them again
Update 2: Magisk 24.1 is now stable. Instructions revised.
Update 3: I contacted phh and he implemented the script inside his trebleapp. Instructions revised and modified trebleapp is attached. NOTE: GSIs newer than 7/Feb/2022 will include this workaround by default.
Update 4: This guide is now unnecessary now that unofficial LineageOS is very close to release

Achievement unlocked: flashed GSI with FBE enabled! ​
{
"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"
}
In short, I've successfully done flashing of @phhusson's latest version of Android 12 GSI (which is v402 as of today). To do this, I needed to modify the multidisabler script so it won't disable FBE, format the userdata using the stock recovery, flash TWRP, resize tmpfs to proper size, push GSI image into tmpfs and flash it using TWRP. I used the securized image with vndklite variant, since there was no securized images for regular vndk releases (but it seemed that vndk was working better for me, at least I have no USB connection anymore where with VNDK I was able to have USB debugging). Maybe I'll try re-flashing it once I'll patch the regular images and securize them (since I'm on *nix, I can just mount them and modify their contents) and take an approach of finding how Samsung ROMs are working OK. For now, I need to take a break from all bootloops I had in the process of FBE flashing .
Anyway, the goal of this experiment was to use GSI ROMs as a daily driver and having FBE disabled could otherwise cause a serious problem on device loss.
So, onto the list what's been tested (that wasn't noted before):
Screen locking – it seems that the workaround for the screen is not applied before unlocking the phone, probably because the app is not running yet. This might work with the script used as postfs module.
EDIT: I've found some notes in the Magisk documentation that both post-fs data and late_start services are run after data is decrypted, which basically means applying this workaround using Magisk seems to be pointless for now (maybe not after PPH app will stop providing the workaround)... Probably the best option would be patching the ROM itself, either with flashable ZIPs or directly before flashing it (most GSIs can be mounted under Linux and tweaked).
Adaptive brightness – not working, since all virtual sensors are not working for now. Might be easy to fix through as I've found some stuff in the official ROM that I had an idea to experiment with putting them into GSIs (as a Magisk module, to avoid a breakage).
USB – as I said, a data transfer via USB is not working for me for some reason. It worked for me once I had VNDK Android 12 GSI installed (same version).
Booting with stock kernel – I had some successful attempts doing that, but it further was a cause of a bootloop, at least once I had installed Magisk. Therefore, I'll recommend patching the Magisk the way as in tutorial (after patching the kernel) to have everything working for now.
For people who wants to play with stock images but don't know how: you can use simg2img, lpunpack and Linux to extract and mount the official ROM image in approach of finding there some tips like in initrc services why some stuff is working fine on Samsung while it doesn't on GSIs. Maybe I would tinker with it a bit, trying to export a few services and libraries in an approach to create a Magisk module with all stuff needed to have a fully functional GSI, but I'm tired of modding for now, especially when this is my first Samsung phone I had to deal with.
Edit: Typo fixes, added additional text formatting.

Amazing work. If you need testers feel free to PM me. As a sidenote, poking in sysfs led me to believe that android is sending the info needed to read the proximity but the kernel is sending garbage which gets interpreted as the sensor not being triggered. Also phh should have added the workaround into his trebleapp starting from phh AOSP 12 v401, so aside from installing magisk no post install workarounds should be needed.
Attached is a photo of what cmd_result reads when a whatsapp voice message is played which reads proximity to play the message in the earpiece and turn screen off when proximity is triggered

ap4ss3rby said:
Also phh should have added the workaround into his trebleapp starting from phh AOSP 12 v401, so aside from installing magisk no post install workarounds should be needed.
Click to expand...
Click to collapse
Unfortunately, the commit was reverted as of master branch, so we should prepare for it to stop to work unless phh will work on it before releasing an another version. Also I wrote that the workaround didn't seem to apply itself before unlocking the phone (FBE encrypted) the first time and therefore decrypting sensitive data after boot. For now this makes it an requirement when using PHH app to unlock the phone before it sleeps so the touch is going to be responsive.
Anyway, it seems that even Magisk (v24.1) is not capable of running the services before data is decrypted, so now I have no idea how to bypass that in other way than patching the ROM itself and creating the `initrc` service... Anyway, this is also a hint that what samsung is doing starts before basically everything, so no APK file nor script is going to really fix it since they are meant to start after data is decrypted...

SB3P said:
Unfortunately, the commit was reverted as of master repo, so we should prepare for it to stop to work unless phh will work on it before releasing an another version. Also I wrote that the workaround didn't seem to apply itself before unlocking the phone (FBE encrypted) the first time and therefore decrypting sensitive data after boot. For now this makes it an requirement when using PHH app to unlock the phone before it sleeps so the touch is going to be responsive.
Anyway, it seems that even Magisk (v24.1) is not capable of running the services before data is decrypted, so now I have no idea how to bypass that in other way than patching the ROM itself and creating the `initrc` service... Anyway, this is also a hint that what samsung is doing starts before basically everything, so no APK file nor script is going to really fix it since they are meant to start after data is decrypted...
Click to expand...
Click to collapse
I guess for now we have two options:
A: Build custom kernel/vendor specifically for GSIs that correctly reports sensors as GSIs expect them to
B: Fix GSI issues through Magisk services implementing various workarounds in scripts. (an example is the touchscreen sleep/wake issue)

ap4ss3rby said:
Attached is a photo of what cmd_result reads when a whatsapp voice message is played which reads proximity to play the message in the earpiece and turn screen off when proximity is triggered
Click to expand...
Click to collapse
Also that's interesting those virtual sensors are still present, I personally thought that Samsung made it the way there's an virtual device create as on Linux and there's their proprietary software running somewhere in the system that uses the camera as an input and calculates it to provide the data... On the other hand, when I think about that logic, even some (if not all) virtual devices on Linux (e.g. v4l2loopback) needs to have their module loaded with the kernel to work. I'm glad at least there's no need to reinvent the wheel and no one really needs to recreate the entire algorithm for it if it's going to be in the kernel sources...
ap4ss3rby said:
I guess for now we have two options (...)
Click to expand...
Click to collapse
I feel like the B option is worse than patching the GSI ROMs, either via flashable ZIPs or on your own... This is because I couldn't find anything in docs that would let me run services before /data is going to be decrypted... Personally, I've made myself a such service using the statically-compiled Linux ARM binary (non-NDK, using GNU libs – yes, it is still runnable on Android as well) – it applies the workaround for now both when screen is turned on and off (I had no idea on which event it should really run, so I made it to run on both just to be safe) by watching the file changes based on (AFAIK) filesystem events – so it has a major advantage over your script, as it won't run in endless loop, yet watch the file responsible for brightness to change and then do its job. But even with that, TSP doesn't seem to make touch available immediately and it is still expected to be revived after 1-2 seconds.
Also, as of the methods of applying these workarounds, the other way could be modifying the ramdisk (maybe with the help of Magisk, which I believe has documented how it's actually doing it itself and how others could modify the root and init as Magisk does to load files before the OS will properly initalize itself. Yet I don't like an idea of messing myself with the boot partition, at least for now...

Debug info: I tried flashing stock to grab logs from the touchscreen driver. The logs attached here do not appear at all on an unpatched GSI (I.E flashing the GSI as is without any touch workaround).

ap4ss3rby said:
Hi, I installed LineageOS 18.1 GSI on my M127F. I want to share my guide to installing this GSI.
Code:
DISCLAIMER:
By following this guide you accept that you
may do irreversible damage to your phone.
If something breaks the responsibility is
yours only. If you want stable software that
is guaranteed to work 100% don't follow
this guide.
I assume you are running a fully stock system and and locked bootloader and firmware U3/U4.
Installing TWRP and custom kernel
Enable Developer Options by tapping on software information > build number 7 times
Enter developer options then toggle OEM Unlocking on.
Power off your phone.
Hold Vol Up + Vol Down then plug in your phone to enter download mode
THIS WILL ERASE ALL YOUR DATA AND VOID YOUR WARRANTY. Follow on screen instructions to unlock your bootloader. THIS WILL ERASE ALL YOUR DATA AND VOID YOUR WARRANTY
After this you want to download and install attached Orangefox recovery using odin. After odin is done flashing enter recovery
Format data (not wipe) in recovery
Enter terminal and type multidisabler twice
Reboot to system and verify that under security encryption is disabled
Download TWRP and custom kernel for your phone
Reboot into recovery and locate the downloaded twrp image
Select recovery.
Reboot into recovery
Install kernel, then wipe cache and reboot. You should now see that it is complaining about some internal issue. This is normal.
Installing the GSI
Download your favorite ROM from the list provided below. You want to install an arm64 a/b image.
Extract the image file
Reboot to recovery.
Select install then install image
Locate the GSI image
Select install system
After that is done return to recovery and select factory reset.
Reboot then do setup (if applicable) then download attached magisk and phh trebleapp. If your phone is stuck on bootanimation check under to fix it.
IMPORTANT: DO NOT LET THE SCREEN TURN OFF OR YOU WILL HAVE TO REBOOT TO MAKE TOUCH WORK AGAIN.
Install attached magisk
Open magisk and click on install then direct install
Download and install the attached phh-treble app apk.
Touch should now work. Enjoy your GSI.
Extras
Magisk 24.1
Open Magisk
Go to settings
Update Magisk Manager app to version 24.1
Relaunch Magisk then install magisk
Choose direct instal
Migrating to patched trebleapp
Download and install attached trebleapp
Open your root file manager
go to /data/adb/service.d
Delete the script you added earlier
Tips in case things don't work
In case after rebooting to the GSI the phone bootloops:
Download stock image from wherever you download your firmware (I use a python program called samloader)
Extract the AP of the downloaded firmware
Find userdata.img.lz4 and create a .tar archive only containing this file
Reboot to download mode
In odin select AP then locate the newly created .tar archive Then click on flash
Reboot
Continue from step 7 under the "Installing the GSI" portion of the guide
To revive the touchscreen using ADB:
In case you didn't grant adb root access but installed magisk, run adb shell then su. A root access for the app shell will appear. Grant root permission
Plug in phone to a computer with ADB
adb shell
su
cat /sys/class/sec/tsp/cmd_result
echo check_connection > /sys/class/sec/tsp/cmd
What works:
Boots
RIL
Fingerprint
Main rear camera
Front camera
Sleep/Wake (workaround in steps above, may need to sleep wake several times before it works)
WiFi
Flashlight
Rotation
Magisk 24
90Hz (M12 only. A12 doesn't have 90Hz refresh rate)
LineageOS 18.1
LineageOS 19
CAOS (GApps variant available)
phh AOSP 11 v313
phh AOSP 12 v400h
Untested
GPS
Flashing GApps. (I use fdroid and aurora store on LineageOS and CAOS has built in GApps)
USB-OTG
A127F
M127G
If I didn't list it under broken or working I didn't try it or forgot to test it.
Broken
Double tap to wake. Touchscreen turns off and I have no idea how to keep it alive while lcd is off
MTP
Virtual Proximity. Screen will stay on in phone calls and WhatsApp will always play voice messages through speaker
Flashlight brightness. Flashlight will always stay on weakest brightness with no way to adjust.
Adaptive refresh. The framerate you set in phh addons is what you get. Be prepared for slightly reduced battery.
You tell me (even though I probably don't have the solution)
Bugs
You may need to wait a little bit before touchscreen responds or sleep/wake several times before screen responds after turning the screen off
Credits
@physwizz for kernel, TWRP and orangefox
@phhusson for implementing workaround in trebleapp as well as GSI list
me for touch workaround
Links
Kernels and recoveries: https://t.me/a127f_res/113
GSIs: https://github.com/phhusson/treble_experimentations/wiki/Generic-System-Image-(GSI)-list
Click to expand...
Click to collapse
Great guide.
Well done

Thanks for the great guide. Unfortunately, I don't know how to resize tmpfs. Can anybody tell me how to do that? I only have 4 GB or less on my Samsung Galaxy A12 with 64 GB of Storage (it should have, it only shows something like 3 or 4 gigabytes like I mentioned)

matahbeyz said:
Thanks for the great guide. Unfortunately, I don't know how to resize tmpfs. Can anybody tell me how to do that? I only have 4 GB or less on my Samsung Galaxy A12 with 64 GB of Storage (it should have, it only shows something like 3 or 4 gigabytes like I mentioned)
Click to expand...
Click to collapse
You don't have to resize TMPFS if you don't want to have FBE encryption or have the external SD card (you can use microSD for flashing, which might be a better choice if you need to flash a larger devices). Also you can't resize TMPFS to 64 GB, it uses your RAM to store regular data instead of storage (this is basically the concept of TMPFS). What I was mentioning is that /data won't work under FBE and custom recoveries for now, so you need to use your RAM instead if you don't have any external storage device to save images somewhere via ADB.
As of resizing the TMPFS, you should be able to find some Linux tutorial how to do that, on Android this is works basically the same (even on both Linux and Android you have /tmp directory with TMPFS by default).
Anyway, I've decided to share some stuff that you may need for that. Here's the multidisabler script I was using for flashing GSIs with FBE encryption preserved. I was also working on the native binary that would work as the workaround for the touchscreen so it can be used instead of the script. The advantages are that it actually listens to filesystem events and therefore does not need to read file in loop in order to get the information if brightness has changed. Maybe I'll share it with you once I find it to be ready, right now I'll just share my multidisabler script with patches.
BTW, I've tested LineageOS GSIs (both 11 and 12) and noticed they behave completely different, no matter of variant (the USB actually uses some driver, which is not fully compatible with M12 but close enough to provide basic communication through ADB). I guess pphusson just changed something and now these drivers aren't applied by default, yet I think I've noticed the issues with Bluetooth's HSP/HFP profiles which as I remember was not the case with latest stable pphusson's vanilla Android 12 GSIs. Now I just hope these problems are going to be resolved in the next builds of Android's GSIs with phhusson's patches and with the knowledge that MTP just worked fine on TWRP I used, there's a little hope that we will gain the proper combination of drivers/firmware to have both USB and Bluetooth functional at the same time someday.
I've also approached patching the kernel under newer kernel base 4.19.112, yet I gave up on properly resolving its conflicts. I may work on that as well in order to patch some vulnerabilities, with a hope that I'll succeed updating kernel as closest to the latest patch as possible. The 4.19.112 is going to be just a test if Samsung is capable of actually booting from it and if I may be able to use git with common human logic and my limited programming skills to actually patch it the way it would do so (without much understanding about the code itself, yet basic knowledge about C syntax). For now I've only succeed reproducing the upstream Linux kernel commit structure from 4.19.111, with a single additional commit for Samsung changes and another one for physwizz ones.

can anyone guide me how to unlock bootloader on Samsung Galaxy M12G ?

@SB3P Thanks so much. Sorry for my late reply, but thank you!

SB3P said:
Achievement unlocked: flashed GSI with FBE enabled! ​View attachment 5533799​In short, I've successfully done flashing of @phhusson's latest version of Android 12 GSI (which is v402 as of today). To do this, I needed to modify the multidisabler script so it won't disable FBE, format the userdata using the stock recovery, flash TWRP, resize tmpfs to proper size, push GSI image into tmpfs and flash it using TWRP. I used the securized image with vndklite variant, since there was no securized images for regular vndk releases (but it seemed that vndk was working better for me, at least I have no USB connection anymore where with VNDK I was able to have USB debugging). Maybe I'll try re-flashing it once I'll patch the regular images and securize them (since I'm on *nix, I can just mount them and modify their contents) and take an approach of finding how Samsung ROMs are working OK. For now, I need to take a break from all bootloops I had in the process of FBE flashing .
Anyway, the goal of this experiment was to use GSI ROMs as a daily driver and having FBE disabled could otherwise cause a serious problem on device loss.
So, onto the list what's been tested (that wasn't noted before):
Screen locking – it seems that the workaround for the screen is not applied before unlocking the phone, probably because the app is not running yet. This might work with the script used as postfs module.
EDIT: I've found some notes in the Magisk documentation that both post-fs data and late_start services are run after data is decrypted, which basically means applying this workaround using Magisk seems to be pointless for now (maybe not after PPH app will stop providing the workaround)... Probably the best option would be patching the ROM itself, either with flashable ZIPs or directly before flashing it (most GSIs can be mounted under Linux and tweaked).
Adaptive brightness – not working, since all virtual sensors are not working for now. Might be easy to fix through as I've found some stuff in the official ROM that I had an idea to experiment with putting them into GSIs (as a Magisk module, to avoid a breakage).
USB – as I said, a data transfer via USB is not working for me for some reason. It worked for me once I had VNDK Android 12 GSI installed (same version).
Booting with stock kernel – I had some successful attempts doing that, but it further was a cause of a bootloop, at least once I had installed Magisk. Therefore, I'll recommend patching the Magisk the way as in tutorial (after patching the kernel) to have everything working for now.
For people who wants to play with stock images but don't know how: you can use simg2img, lpunpack and Linux to extract and mount the official ROM image in approach of finding there some tips like in initrc services why some stuff is working fine on Samsung while it doesn't on GSIs. Maybe I would tinker with it a bit, trying to export a few services and libraries in an approach to create a Magisk module with all stuff needed to have a fully functional GSI, but I'm tired of modding for now, especially when this is my first Samsung phone I had to deal with.
Edit: Typo fixes, added additional text formatting.
Click to expand...
Click to collapse
Could you explain how you done this.... i mean please explain step by step... i am using Galaxy M12G Varient....thanks in advance

milindbhaliwade said:
Could you explain how you done this.... i mean please explain step by step... i am using Galaxy M12G Varient....thanks in advance
Click to expand...
Click to collapse
If you would see the *untested* section at the initial post of this thread, it is unknown whetever this works or not for M127G phones (if it bootloops it might not work at all). Anyway, here's how I did it on M127F (at least how I remember this):
1. I did steps from 1-6, I believe I skipped 7 since I was aware it will mess something up with the data partition.
2. I modified the multidisabler script and pushed it to my phone via the ADB (to TMPFS). You can find this script pushed as xz compressed file. Before executing multidisabler script I have done a backup of the recovery and system partitions (using dd tool) which I am going to reflash later.
3. I rebooted to download mode and flashed TWRP image.
4. After TWRP ended flashing, I booted into the recovery. I flashed the physwizz kernel and then my own GSI image as it was described in the instructions at the initial post. Just remember that /data partition is not functional with FBE and TWRP so you need to push your images somewhere else like microSD card or TMPFS partition. OTG might work here as well, this is something I haven't tested yet through...
5. Once you are done with flashing you need to restore the original recovery partition via the download mode. TWRP won't boot the GSIs with FBE encryption enabled actually it does boot now for me, yet I still recommend switching to stock recovery if your phone bootloops or you need to format/wipe userdata partition. You can then safely format your /data partition with the stock recovery.

ap4ss3rby said:
Hi, I installed LineageOS 18.1 GSI on my M127F. I want to share my guide to installing this GSI.
Code:
DISCLAIMER:
By following this guide you accept that you
may do irreversible damage to your phone.
If something breaks the responsibility is
yours only. If you want stable software that
is guaranteed to work 100% don't follow
this guide.
I assume you are running a fully stock system and and locked bootloader and firmware U3/U4.
Installing TWRP and custom kernel
Enable Developer Options by tapping on software information > build number 7 times
Enter developer options then toggle OEM Unlocking on.
Power off your phone.
Hold Vol Up + Vol Down then plug in your phone to enter download mode
THIS WILL ERASE ALL YOUR DATA AND VOID YOUR WARRANTY. Follow on screen instructions to unlock your bootloader. THIS WILL ERASE ALL YOUR DATA AND VOID YOUR WARRANTY
After this you want to download and install attached Orangefox recovery using odin. After odin is done flashing enter recovery
Format data (not wipe) in recovery
Enter terminal and type multidisabler twice
Reboot to system and verify that under security encryption is disabled
Download TWRP and custom kernel for your phone
Reboot into recovery and locate the downloaded twrp image
Select recovery.
Reboot into recovery
Install kernel, then wipe cache and reboot. You should now see that it is complaining about some internal issue. This is normal.
Installing the GSI
Download your favorite ROM from the list provided below. You want to install an arm64 a/b image.
Extract the image file
Reboot to recovery.
Select install then install image
Locate the GSI image
Select install system
After that is done return to recovery and select factory reset.
Reboot then do setup (if applicable) then download attached magisk and phh trebleapp. If your phone is stuck on bootanimation check under to fix it.
IMPORTANT: DO NOT LET THE SCREEN TURN OFF OR YOU WILL HAVE TO REBOOT TO MAKE TOUCH WORK AGAIN.
Install attached magisk
Open magisk and click on install then direct install
Download and install the attached phh-treble app apk.
Touch should now work. Enjoy your GSI.
Extras
Magisk 24.1
Open Magisk
Go to settings
Update Magisk Manager app to version 24.1
Relaunch Magisk then install magisk
Choose direct instal
Migrating to patched trebleapp
Download and install attached trebleapp
Open your root file manager
go to /data/adb/service.d
Delete the script you added earlier
Tips in case things don't work
In case after rebooting to the GSI the phone bootloops:
Download stock image from wherever you download your firmware (I use a python program called samloader)
Extract the AP of the downloaded firmware
Find userdata.img.lz4 and create a .tar archive only containing this file
Reboot to download mode
In odin select AP then locate the newly created .tar archive Then click on flash
Reboot
Continue from step 7 under the "Installing the GSI" portion of the guide
To revive the touchscreen using ADB:
In case you didn't grant adb root access but installed magisk, run adb shell then su. A root access for the app shell will appear. Grant root permission
Plug in phone to a computer with ADB
adb shell
su
cat /sys/class/sec/tsp/cmd_result
echo check_connection > /sys/class/sec/tsp/cmd
What works:
Boots
RIL
Fingerprint
Main rear camera
Front camera
Sleep/Wake (workaround in steps above, may need to sleep wake several times before it works)
WiFi
Flashlight
Rotation
Magisk 24
90Hz (M12 only. A12 doesn't have 90Hz refresh rate)
LineageOS 18.1
LineageOS 19
CAOS (GApps variant available)
phh AOSP 11 v313
phh AOSP 12 v400h
Untested
GPS
Flashing GApps. (I use fdroid and aurora store on LineageOS and CAOS has built in GApps)
USB-OTG
A127F
M127G
If I didn't list it under broken or working I didn't try it or forgot to test it.
Broken
Double tap to wake. Touchscreen turns off and I have no idea how to keep it alive while lcd is off
MTP
Virtual Proximity. Screen will stay on in phone calls and WhatsApp will always play voice messages through speaker
Flashlight brightness. Flashlight will always stay on weakest brightness with no way to adjust.
Adaptive refresh. The framerate you set in phh addons is what you get. Be prepared for slightly reduced battery.
You tell me (even though I probably don't have the solution)
Bugs
You may need to wait a little bit before touchscreen responds or sleep/wake several times before screen responds after turning the screen off
Credits
@physwizz for kernel, TWRP and orangefox
@phhusson for implementing workaround in trebleapp as well as GSI list
me for touch workaround
Links
Kernels and recoveries: https://t.me/a127f_res/113
GSIs: https://github.com/phhusson/treble_experimentations/wiki/Generic-System-Image-(GSI)-list
Click to expand...
Click to collapse
try to install @phhusson (system-squeak-arm64-ab-vndklite-gapps-secure.img) GSI using above method on Samsung Galaxy M12G (SM-M127G) BUT failed to boot up
facing following issue:
1) unable to boot in OrangeFox Recovery
2) boot in TWRP Recovery but not detected MicroSD Card
3) samehow manage to push Kernal.zip, SystemGSI.img by adb push file_name_with_extension /sdcard BUT not flash properly as TWRP reboot again and again in 2-3 minutes
so friends, don't try this method on Samsung Galaxy M12G (SM-M127G) unless Senior member come up with this specific model

For anyone who has starred this thread, I and other devs have released a proper build of LineageOS with /vendor. Aside from VoLTE (which I don't think worked in GSIs anyways) everything should work. Moderators, please close this thread

ap4ss3rby said:
For anyone who has starred this thread, I and other devs have released a proper build of LineageOS with /vendor. Aside from VoLTE (which I don't think worked in GSIs anyways) everything should work. Moderators, please close this thread
Click to expand...
Click to collapse
LineageOS is not only GSI available, I think someone might still find it useful if they want to flash another ROMs. Also Phhuson's GSI also contains some features that unofficial GSI release don't have (i.e. flashlight control in Phhusson's app), so they still might be useful for someone.
This is why I think it is better to not close this thread and maybe revive original guide.

SB3P said:
LineageOS is not only GSI available, I think someone might still find it useful if they want to flash another ROMs. Also Phhuson's GSI also contains some features that unofficial GSI release don't have (i.e. flashlight control in Phhusson's app), so they still might be useful for someone.
This is why I think it is better to not close this thread and maybe revive original guide.
Click to expand...
Click to collapse
Our rom is built completely from source, not a GSI, and it is more or less a complete replacement of stock firmware. If you want you can use a GSI over that instead, and it should function much better than just replacing stock firmware

ap4ss3rby said:
Our rom is built completely from source, not a GSI, and it is more or less a complete replacement of stock firmware. If you want you can use a GSI over that instead, and it should function much better than just replacing stock firmware
Click to expand...
Click to collapse
I haven't said GSI are better, I personally use this unofficial LineageOS build. But what I've said, GSI brings much more variety of picking the OS you can install. Even Linux can be installed on phones nowadays using GSI with only Halium-patched kernel as an requirement. This is why I think leaving this tutorial archived (no updates, interest on fixing bugs etc.) is better than removing it.

stayboogy [ROM] AOSP 12.0.0_r3 [straight from android.googlesource.com]

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.