Related
Are any devs working on a method to repartition the Pixel? It seems that most flashing issues are due to the A/B partition scheme. Also, in the case of custom ROMs, the duplicate partitions are a waste of space (unless you want to dual boot, which doesn't work well either since the data partition is shared).
Anyway, it would be awesome if the Pixel could be repartitioned.
I think this is highly unlikely. The Nexus 7 had a laughably small system partition, which led to people being SOL when trying to get newer Android versions and gApps to work together. The other reason this is unlikely is because it's a pretty dangerous process (mess something up and you might completely brick the device, since factory images don't do any partitioning work), and this would modify the hashes used by SafetyNet, so there would be no easy way of passing the CTS checks.
The a/b partitions weren't made for dual booting, they were made for google and ota's/updates
Now, you can dual boot with the same custom rom, one rooted, the other non-rooted same with stock.
Sent from my Pixel using XDA-Developers Legacy app
creeve4 said:
Are any devs working on a method to repartition the Pixel? It seems that most flashing issues are due to the A/B partition scheme. Also, in the case of custom ROMs, the duplicate partitions are a waste of space (unless you want to dual boot, which doesn't work well either since the data partition is shared).
Anyway, it would be awesome if the Pixel could be repartitioned.
Click to expand...
Click to collapse
What space are you wasting? Its the system partition. The biggest reason I think that it exists is for the seamless updates. Its also a redundancy should you not be able to boot or an OTA fries your device.
The only issues I have ever had (and most of the ones I have encountered) were users not doing research. Its not hard to flash on this device, its just that details arent laid out very well and up to date in any one spot.
As you all know GSI image alone not sufficient to get fully functional robust stable OS running on Lenovo p2. There are many flashable zip files which need to be flashed individually to get most of the features working. Which makes GSI image meaning less.
So post/discuss all the available GSI and device specific features for Lenovo P2 here.
It will be helpful for Devs and users.
** Requesting Devs to work on device specific feature support over GSI image. **
So far our Dev helped us getting up to this level. We need little more effort to make the GSI image successful on our device.
Expecting Users active support for Devs.
Edited: request only to make device specific features which lacks in GSI image.
Refer post #3.
What do you mean by device specific GSI? What's the point of doing this while GSI (Generic) means (for us) that you can actually flash it over multiple Treble devices out there?
If you recompile system image with device specific patches it will be basically device specific standard ROM (but with Treble which is basically not needed now) and not GSI anymore.
I don't get why are you people actually need "Treble" compatible ROM while existing standard ROMs are working great for now. Because they're Treble ROMs? What does it change? GSIs created using phhusson scripts are one big hack at the moment and their state is experimental. Of course they will work but they're lacking of device specific build.prop's.
Oreo one's are actually fully compatible with Lenovo P2 and stable because I tested them myself. Probably all of them (but all I tested) share the same device specific bugs. Even FP gestures works but this function needs to be activated by "setprop persist.sys.fp.navigation 1" after boot. The fix zip provided in P2 Mods subforum is actually copying script to system which will actually do that after every boot, nothing more. Google told on their AMA that they will make official documentation of making GSIs in the near future so I believe that will fix our current problems and device specific build.props could be generated and added to ROMs without touching system partition integrity state and recompiling them.
Until Android Pie ROMs will be stable as GSIs you will also not benefit too much from creating device specific system image because you will need to wait for Mike or someone else to create compatible vendor image and kernel (Probably Mike will be the first so you will need to wait for official release of LOS16).
Recompiling ROMs just for adding few fixes is a waste of resources. You need approx ~250GB of memory to compile and maitain one ROM, time (depending on memory you are using) and a lot of electricity.
In my personal opinion, creating Magisk module for P2 devices which will fix build.prop systemless-ly and add that command for activating FP gestures will be better alternative for now. I could personally look into it when I get some time.
If you still think that you need these device specific system images for every ROM at all costs, you could build them and maitain yourself or ask someone who will do this. Maybe Fullbustah will be eager to do some requests because he already built some popular ROMs on Mike's sources lately. You could also extract system.img's from his last builded ROM's and they will be device specific system images you are looking for . The only problem is that I don't think he is willing to maitain all of them at once.
I'm sorry if my previous post conveyed wrongly.
All we need is GSI images should be flashed directly. I didn't conveyed anywhere to build a sperate image from GSI.
May be I asked to maintain device specific vendor/system tweaks in a one place which will be flashed on top of any GSI image to get all the features working in our device.
Hope this helps!
MAILUS said:
I'm sorry if my previous post conveyed wrongly.
All we need is GSI images should be flashed directly. I didn't conveyed anywhere to build a sperate image from GSI.
May be I asked to maintain device specific vendor/system tweaks in a one place which will be flashed on top of any GSI image to get all the features working in our device.
Hope this helps!
Click to expand...
Click to collapse
Ah, okay. It changes a lot. I tested few Oreo GSIs about a month ago an everything was working fine and stable for me. The only tweak needed was FP gesture fix but it was messing with the system partition and I was too lazy to make to improve it so I just gave up using it. And another missing thing was build.prop because device is named "Phh's Treble ARM64" or something like that after installing GSI. Also build fingerprint is always messed up so I had problems passing SafetyNet even with Magisk.
Only these fixes are required for making Oreo GSI's working perfectly or almost perfectly (like official LOS) so I'm going to do Magisk module that will cumulate all of these fixes into one, easy to install solution. If I missed something just let me know.
Hi,
I have a Samsung S9+ (star2lte) on which I installed e os 1. This is essentially Lineage with a some tweaks and e Recovery. I would like to root my device, so that I can install AFWall+. Open to alternatives, but most don't offer a comparable deal in term of privacy, security and sideeffects. I will probaby also need MAgisk to hide root from banking apps. So I decided to go for Magisk, which I have used in the past as well.
So there is no lack of guides when you search for this topic. However, noone mentions e os. And this twist seems to matter. While trying to follow various guides (I have by now started from factory a couple of times, as I almost bricked my device...)., I came across a lot of errors, which were not mentioned in either guide. The install would fail, sometimes messing up the entire installation, so that I had to start from scratch.
I think I identified one of the main issues, which happens to be the recovery. The e Recovery won't install the proper magisk boot image. Well, unless there was another issue in the background, but I also found hints towards TWRP being needed to install magisk. So I installed TWRP latest version, which worked fine. Then I tried to install magisk boot image - and it failed. /data could not be mounted, apparently this relates to the encryption of the file system.
I'm also about unclear on the role of Odin (latest). I understand I need it to flash my Samsung device, e.g. with TWRP. I'm somehwhat unclear on the various filetypes one can flash (AP, BL, CSC,...). So I strictly adhere to the guides for this. MEaning, I have never tried to flash Magisk via Odin - is that possible? Does it make sense? How?
One sideeffect of the guides I found would be, that TWRP is installed as recovery. In an ideal solution, I would like to return to e os recovery, so that everything is as close to the orignal setup as possible, except with root (and possibility to hide this for specific apps).
As I have spent two days backing up, flashing, reading guide, reading more guides and still failing all the time with results which forced me to redo everything from vendor image - I finally resorted to asking for help here. Can someone please guide me though the process of installing magisk?
Versions:
Samsung SM-965F DBT (star2lte)
e os 1.0-q-2022052618889-stable-star2lte
TWRP 3.6.1_9_0-star2lte
Odin 3.14.4
Magisk: Latest App.
Best,
YeOldHinnerk
same problem with a oneplus 5, i updated to e/os/ 1.0 and no more magisk/root...i try to update with magic manager (magisk 25), it asks a patch but not proposing install...
You need to extract the boot.img from e. Download the tar/zip, extract and locate the boot.img within. Copy that somehhere on your phone and feed it to magisk.
TWRP will not see the file by magisk since the file system is encrypted, see above.
Btw encryption is a must-have for me, for security reasons and my apps for work won'T run without (Citrix Secure Hub).
it's working Thks a lot !
Was intended as llooking for help here - but glad I could help too
Hi @YeOldHinnerk & @pommedefrance , I wonder if you'd mind taking a look at my post:
Magisk General Support / Discussion
This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases. All information, including troubleshoot guides and notes, are in the Announcement Thread
forum.xda-developers.com
Same issues but with Samsung S7.
Any pointers?
Thx
I don't know if this is the right place to ask or if it already has been or not, but is there any possible way to get 32 bit apps to run in some type of compatibility mode or something like that? For the most part the majority of my old apps came over from my old phone, however there are some apps I have and used regularly which are not compatable with this phone and I am not sure if the developers are still active or not. I'm assuming the answer is no, or would require root if it were possible and rooting is out of the question for me because I have Verizon. I am expecting to be SOL but figured it was worth asking about here.
This question has been asked and discussed in length, try search
I will not be rude and the short answer is no. Apps on the play store had roughly 2 years to switch 64 bit. For s**ts and giggles I did try to do a search with zero results.
If the devs are still active and they havn't updated to 64bit by now then they are a lost cause.
No Google's heads up to devs gave them ample amounts of time to switch all their apps from 32bit over to 64bit. Tough shiz if the devs didn't take the arning seriously and switched their apps over whenthey had the cance to do so. I'm genuinely curious of 32bit compatibility is a concern and/or a necessity for you why you would buy a smartphone that doesn't support it? I really don't see how that makes much sense when you could have chose from a lot of other new flagships with 32bit support in tact.
Get a Galaxy S22 Ultra, Motorola Edge 30 Ultra or OnePlus 10 Pro. It's likely next year's flagships of any brand will be 64 bit only, so the forced shift is coming.
I did not even know this was a thing prior to buying the phone and don't remember seeing anything posted about it until after I got the phone and google'd and found people talking about it on reddit but I did not find anything on here going into detail about it.
I never stated it was a "necessity" and I have no idea if the developers are active or not. They are older apps that are not overly popular that everyone uses however they were things I used on a regular basis and have no idea how I would even check to have known if they were 32 or 64 bit until I got the new phone and they didn't work and wouldn't let me install them. It's not the absolute end of the world, it's just an inconvenience and means I need to try and find replacements or reach out to the devs but it doesn't hurt to ask here because I figured there would be a way around it but obviously not.
This might be of some help to run 32 bit apps you want:
GitHub - ThomasKing2014/Pixel7_32bit_helper
Contribute to ThomasKing2014/Pixel7_32bit_helper development by creating an account on GitHub.
github.com
Interesting I will have to check this out
Not working for my Pixel 7 Pro, version 13 (TD1A.221105.001) : (
I dirty flash patched init_boot.img, and replace Magisk app to initial version of that repo.
VergeDX said:
Not working for my Pixel 7 Pro, version 13 (TD1A.221105.001) : (
I dirty flash patched init_boot.img, and replace Magisk app to initial version of that repo
Click to expand...
Click to collapse
Remove "stock' magisk
Install the patched magisk apk
Patch the stock init boot with the patched magisk apk
Flash the new patched init boot
on a clean install it works for me (beta: cheetah-t1b3.221003.008)
lunacies said:
I did not even know this was a thing prior to buying the phone and don't remember seeing anything posted about it until after I got the phone and google'd and found people talking about it on reddit but I did not find anything on here going into detail about it.
I never stated it was a "necessity" and I have no idea if the developers are active or not. They are older apps that are not overly popular that everyone uses however they were things I used on a regular basis and have no idea how I would even check to have known if they were 32 or 64 bit until I got the new phone and they didn't work and wouldn't let me install them. It's not the absolute end of the world, it's just an inconvenience and means I need to try and find replacements or reach out to the devs but it doesn't hurt to ask here because I figured there wld be a way around it but obvio
Click to expand...
Click to collapse
That's what I meant by and or sorry if me misinterpreting what you meant
bhammler said:
on a clean install it works for me (beta: cheetah-t1b3.221003.008)
Click to expand...
Click to collapse
I've compiled Magisk with the supplied patch from the repo and it isn't working for me. I've verified that the init does include the changes to override ro.zygote, however none of the Zygote processes start as the adb server never starts up, and well it doesn't boot.
Tested with the modified Magisk APK from the repo, same deal.
Strange that a clean install is necessary.
don't bother with a clean install, after I've installed some Mgaisk modules, I had a bootloop ;-)
It's nice to see there may be an option and I hope it works for everyone else. I am stuck with a Verizon phone so rooting is out of the question for me and I figured something like this would require root but hopefully other people are successful in getting it to work.
This works now, the problem was not the modules. If you enabled the zygisk in the 24 manager app than you got stuck in the bootlogo „G“. It’s fixed now, there is a new 25 magisk patched manager app that works with zygisk enabled. All my 32 Bit apps working now.
Wouldn't it be easier to just patch build.prop with a magisk module instead of patching the boot image?
Pixel7_32bit_helper/patch.diff at main · ThomasKing2014/Pixel7_32bit_helper
Contribute to ThomasKing2014/Pixel7_32bit_helper development by creating an account on GitHub.
github.com
hahimot483 said:
Wouldn't it be easier to just patch build.prop with a magisk module instead of patching the boot image?
Pixel7_32bit_helper/patch.diff at main · ThomasKing2014/Pixel7_32bit_helper
Contribute to ThomasKing2014/Pixel7_32bit_helper development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
No as I discuss here.
Namelesswonder said:
Didn't sleep, I have gotten closer, but Magisk modules aren't going to be the solution.
The earliest Magisk allows you to modify properties is after the post-fs-data trigger, which is well inside the init.rc. This is problematic because the property needs to be set before init.rc is even read.
Using a Magisk module to replace the init.rc with something else also isn't possible, since Magisk doesn't setup the overlays until well into the boot process.
This replacing is necessary because init.zygote64_32.rc actually has the secondary zygote service disabled, so the file needs to be modified to enable it, or with control over init.rc just stuffing a custom zygote service into it.
I don't think slipstreaming a modified init.rc and init.zygote64_32.rc into the ramdisk in init_boot will work since they would be overwritten once the system partition mounts. Could just modify the system partition, but that'll be for another day.
Click to expand...
Click to collapse
Gerr1 said:
This works now, the problem was not the modules. If you enabled the zygisk in the 24 manager app than you got stuck in the bootlogo „G“. It’s fixed now, there is a new 25 magisk patched manager app that works with zygisk enabled. All my 32 Bit apps working now.
Click to expand...
Click to collapse
Does it? I tried with building my own 24300, 25200, and 25205 and the result was the same on all of them. I didn't remove all modules and kept Zygisk on, so I guess I will have to try completely deleting all Magisk data.
Namelesswonder said:
No as I discuss here.
Does it? I tried with building my own 24300, 25200, and 25205 and the result was the same on all of them. I didn't remove all modules and kept Zygisk on, so I guess I will have to try completely deleting all Magisk data.
Click to expand...
Click to collapse
Yes it works now with the new magisk Manager APK.
I understand that the TWRP team is apparently still working on an official release for Android 13, but is there even an unofficial build available for the P7Pro? If not, is there a recovery alternative? I really want to be able to do a full system (all partitions) backup of my device. Thanks!
You can create dumps of your partitions using ADB shell in system; TWRP is not required to do this.
Though it wouldn't necessarily be any good for doing full partition backups, I'm currently running the recovery from the StagOS ROM in combination with the stock Pixel ROM. I like it because it allows flashing recovery zips without having to say "Yes" every time due to signature stuff.
A very similar thread with the same topic has been discussed a few days ago - you can check here
Anyone can compile TWRP - it's opensource. Pixel 6+ owners are unlikely to get an official build from TWRP since it requires a volunteer to maintain the repo, deal with bug reports, etc.
It's recommended to simply compile the image on an individual basis (you really don't want to rely on a third-party supplied image when you have no way of knowing whether it's safe or not). Compiling isn't a difficult process, but does require an hour or two of reading TWRP's and Google's applicable developer pages, along with ~30 - 60 minutes of set up time on a PC/laptop (I prefer to compile within an Ubuntu VM, but I believe it can also be done in Windows' WSL).
robroy90 said:
I understand that the TWRP team is apparently still working on an official release for Android 13, but is there even an unofficial build available for the P7Pro? If not, is there a recovery alternative? I really want to be able to do a full system (all partitions) backup of my device. Thanks!
Click to expand...
Click to collapse
They still haven't finished official support for Android 12. Since recovery resources on A12+ are located in vendor_boot, bigbiff is trying to figure out a decent way for TWRP to live there, at least as far as the Pixel 5 is concerned. Not sure what other obstacles may be present on the Pixel 6 series and above.
nooted1 said:
Though it wouldn't necessarily be any good for doing full partition backups, I'm currently running the recovery from the StagOS ROM in combination with the stock Pixel ROM. I like it because it allows flashing recovery zips without having to say "Yes" every time due to signature stuff.
Click to expand...
Click to collapse
Hey thanks for this! How did you flash just the recovery partiton on the Pixel? I am an old hand with Odin on the Samsung devices, but Google official devices are still new to me. Will the StagOS recovery recognize an external USB-C flash drive for storage?
s3axel said:
A very similar thread with the same topic has been discussed a few days ago - you can check here
Click to expand...
Click to collapse
Thank you, I went over there and read everything. Much appreciated!