Related
I couldn't find a thread addressing this via Thread Search, so if one exists, please simply reply with a linkDevice: Pixel XL
OS: LOS 16.0
Recovery: LOS
Replicatable: Yes
Upon rebooting after updating via Settings - Updater, device is crippled and unusable, as every single Google app and service crashes. The only way to rectify is boot to recovery, reinstall OpenGApps, and redo Android OOBE.
Even after doing so, because the System partition was shrunk to 2GB for the A/B Partition setup, it's no longer possible to update all Google Apps via OpenGApps (at most only a handful can be installed via OpenGApps), requiring the manual uninstallation of 90% of Google apps via the PlayStore, then manually reinstall each individually.
This results with an update taken via Updater requiring over an hour of manual intervention to rectify what the Updater breaks (it's faster to simply wipe the System Partition and re-install, which is not a realistic solution every week).
JW09I4 said:
I couldn't find a thread addressing this via..........
Click to expand...
Click to collapse
I don't have this device myself but, I believe that this is specific to TWRP...
The following are some helpful links that may have an issue already submitted as well as where to go to submit a new issue (if necessary).
TWRP Issues Page on Github - Search Results for "marlin"
TWRP Issues Page on Github - Search Results for "pixel xl"
TWRP Issues Page on Github - All/Submission of/for Issue(s)
Or you have the following thread options to go to for some support and guidance as well.
https://forum.xda-developers.com/showthread.php?t=3500312
https://forum.xda-developers.com/showthread.php?t=3825866
https://forum.xda-developers.com/showthread.php?t=3489005
Good Luck!
~~~~~~~~~~~~~~~
Unless asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX Forum App on my Apple Macintosh.
Ibuprophen said:
I don't have this device myself but, I believe that this is specific to TWRP...
Click to expand...
Click to collapse
Thank you for the information, however TWRP isn't being utilized.
Even if TWRP has been flashed before an update, it's automatically overwritten by the updater with LOS' Recovery on devices with A/B partitions (due to the kernel no longer being separate IIRC).
I figured I'd give this a day or two in case anyone has run across this with devices utilizing A/B partitions, as it's specific to the online update (i.e. being booted to the OS while the OS is being updated) method of A/B partitions, and if no one has, I'll file a bug report with Lineage, linking to it.
Hi, did you ever file that bug report?
lord high executioner said:
Hi, did you ever file that bug report?
Click to expand...
Click to collapse
I forgot and did not. Lineage did resolve the issue within three months or so afterward, but I'm not sure with what commit.
TWRP HH for Nexus 5
About:
TWRP is an open source, community project. TWRP development is done by roughly 4 people at this point. We also have a large support community with many people who are willing to answer questions and help people with their devices either through our IRC channel or on forums like xda-developers.
Team Win was originally formed to work on porting WiMAX to CM7 for the HTC EVO 4G. After our work on the EVO 4G we wanted to work on a project that would work on more devices than just the EVO 4G and we settled on working on a recovery. Today TWRP is the leading custom recovery for Android phones.
A custom recovery is used for installing custom software on your device. This custom software can include smaller modifications like rooting your device or even replacing the firmware of the device with a completely custom "ROM" like OmniROM
Click to expand...
Click to collapse
Disclaimer:
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this RECOVERY
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
You can find the source code for TWRP on GitHub. If you would like to contribute to TWRP, please visit Gerrit Code Review.
Features:
HH.S version with stock partitions map. S means stock.
HH.R version with repartition support. R means repartition.
Working decryption on custom roms. Tested on LOS 16.0, LOS 17.1, LOS 18.1, but should work on all Androids since Nougat.
exFAT and NTFS support (read and write) for USB OTG
Requirements:
You need to have an unlocked bootloader to install and use TWRP!
Known bugs:
Everything looks good so far
Downloads:
https://sourceforge.net/projects/hammerhead-twrp/files/beta/
Credits:
TeamWin
@Clamor
@steadfasterX
And all the contributors out there in the community
Contributors:
@z3DD3r
Source Code:
Device tree: https://github.com/z3DD3r/twrp_android_device_lge_hammerhead
Version Information:
Satus: Stable
TWRP version: 3.7.0_9
HH Project versions: HH.S.17 and HH.R.17
Created: 2020-02-08
Last Updated: 2022-02-06
Repartition (HH.R versions)
ALWAYS DO THE BACKUPS!!!
No one is responsible for your actions!
Repartition may potentially brick your device, although risk is reduced to minimum.
Features:
Increases /system partition to ~1444Mb
Decreases /cache partition to ~255Mb
Doesn't provide /vendor partition
Doesn't touch /data partition
Requirements:
Not modified partitions by any other solutions
How to increase /system partition and change partitions map:
- Flash the HH.R version of TWRP and launch it
- Open terminal (TWRP -> Advanced -> Terminal)
- Type hh_repart -m
- Wait until your phone reboots
- Install your rom
How to revert back to stock /system size and stock partitions map:
- Launch HH.R version of TWRP
- Open terminal (TWRP -> Advanced -> Terminal)
- Type hh_repart -r
- Wait until your phone reboots
- Flash official TWRP or HH.S version of TWRP! Don't ignore this step!
- Install your rom
How to dump partitions map:
- Launch HH.R version of TWRP
- Open terminal (TWRP -> Advanced -> Terminal)
- Type hh_repart -d
- Wait until process finishes
- Look at /sdcard/partitions.log file
reserved
reserved
Some technical notes about the decryption and Android Q support.
Right now the only possible way to decrypt data on our devices is to use system's vold. This logic was added to TWRP some time ago but one required change wasn't in the tree. This change is here: https://gerrit.twrp.me/c/android_bootable_recovery/+/1919. Without this patch system's vold will fail on hammerhead. I don't know why but services in the sbin can't handle decryption. Also using the system's vold means that ROM should be installed to decrypt data. Without installed ROM decryption is not possible!
About SAR and Android Q. Work on SAR support in TWRP is still in progress but some patches are already available on gerrit. These patches are required to properly detect SAR and mount partitions. Also since Android Q one more service should be run before trying to decrypt data. This service is apexd. Android Q runs apexd on early-init stage to provide required runtime libraries. U can see how it launched at https://android.googlesource.com/pl...fs/tags/android-10.0.0_r29/rootdir/init.rc#37. Only after that step all other services like qseecomd, hwservicemanager, servicemanager and keymaster can be run from system or vendor.
The last point is prebuilt vdc. Prebuilt vdc_pie which is shipped with TWRP fails to run because of linker error. I don't remember exactly what was the error but i guess that something is removed in libc. To fix that problem i've built vcd_ten binary with Android Q sources and placed it into device tree for hammerhead as a temporary solution. The source code of that binary is identical to vdc_pie which located at https://github.com/TeamWin/android_...b/android-9.0/crypto/vold_decrypt/vdc_pie.cpp
This is just a quick notes about what was done.
Patched bootable_recovery is located at https://github.com/z3DD3r/twrp_android_bootable_recovery/tree/android-9.0
Device tree for Q located at https://github.com/z3DD3r/twrp_android_device_lge_hammerhead/tree/q-sar
I hope this will be helpful for TWRP Team!
PS: Changes i've made should be improved. Don't treat them as production ready and/or stable!
FYI @Dees_Troy
Hi, thank you very much for this solution.
hh_repart -d - worked but I couldn't read the log file before rebooting, maybe it's obvious
hh_repart -m - worked without any issues
I have also successfully flashed Lineage 17.1 from your other thread, gapps and Magisk.
New versions are up (HH.S.3 and HH.R.3)
Added exFAT and NTFS support (read and write) for USB OTG
Kernel image is compressed with XZ LZMA2 compression algorithm (smaller size of the recovery image)
New versions are up (HH.S.4 and HH.R.4)
Fixed mounting issues of the system partition
Fixed device overheating while in recovery
I highly suggest everyone update to this version!
I have a question, certainly not in any way a complaint.
I have been running HH4 for a few days. Last night I made a TWRP backup of my LineageOS 17.1, which I installed on 20th without Gapps to see how it works without Google - quite well, in fact, with the help of APK Updater.
This morning I stupidly applied the 22nd update with Gapps - I was on autopilot and forgot that this device had no Google.
No problem, I thought, I'll just restore last night's backup. So I did a total wipe and format ("yes"), but no backup will restore. I just get the LOS line-&-circle animation for ages. I've tried earlier backups, and even standard unmodified TWRP, all with the same result. No backup will restore.
It's not a big deal - I can start with a totally new installation - but I'd like to know if anyone has taken a backup and successfully restored it. Or am I just lucky...? If I can't restore, then it sort of defeats the point of TWRP, no?
Edit: Seriously, 85 people have downloaded HH4. Has not a single one of you tried a restore of a backup?
Edit: Tumbleweed...
Edit: Do I take it that nobody has tried to restore a backup? If you haven't, and my experience is normal, then we're risking a two-hour fresh install in case of update problems rather than a two-minute restore.
dahawthorne said:
I have a question, certainly not in any way a complaint.
I have been running HH4 for a few days. Last night I made a TWRP backup of my LineageOS 17.1, which I installed on 20th without Gapps to see how it works without Google - quite well, in fact, with the help of APK Updater.
This morning I stupidly applied the 22nd update with Gapps - I was on autopilot and forgot that this device had no Google.
No problem, I thought, I'll just restore last night's backup. So I did a total wipe and format ("yes"), but no backup will restore. I just get the LOS line-&-circle animation for ages. I've tried earlier backups, and even standard unmodified TWRP, all with the same result. No backup will restore.
It's not a big deal - I can start with a totally new installation - but I'd like to know if anyone has taken a backup and successfully restored it. Or am I just lucky...? If I can't restore, then it sort of defeats the point of TWRP, no?
Edit: Seriously, 85 people have downloaded HH4. Has not a single one of you tried a restore of a backup?
Edit: Tumbleweed...
Edit: Do I take it that nobody has tried to restore a backup? If you haven't, and my experience is normal, then we're risking a two-hour fresh install in case of update problems rather than a two-minute restore.
Click to expand...
Click to collapse
Have u tried to restore backup of other ROMS? I guess it is not TWRP's problem...
dahawthorne said:
I have a question, certainly not in any way a complaint.
I have been running HH4 for a few days. Last night I made a TWRP backup of my LineageOS 17.1, which I installed on 20th without Gapps to see how it works without Google - quite well, in fact, with the help of APK Updater.
This morning I stupidly applied the 22nd update with Gapps - I was on autopilot and forgot that this device had no Google.
No problem, I thought, I'll just restore last night's backup. So I did a total wipe and format ("yes"), but no backup will restore. I just get the LOS line-&-circle animation for ages. I've tried earlier backups, and even standard unmodified TWRP, all with the same result. No backup will restore.
It's not a big deal - I can start with a totally new installation - but I'd like to know if anyone has taken a backup and successfully restored it. Or am I just lucky...? If I can't restore, then it sort of defeats the point of TWRP, no?
Edit: Seriously, 85 people have downloaded HH4. Has not a single one of you tried a restore of a backup?
Edit: Tumbleweed...
Edit: Do I take it that nobody has tried to restore a backup? If you haven't, and my experience is normal, then we're risking a two-hour fresh install in case of update problems rather than a two-minute restore.
Click to expand...
Click to collapse
With TWRP 3.3.1-HH.R.4 nanroid backup and restore in LOS 14.1 with encyption = ok
With TWRP 3.3.1-HH.R.4 nanroid backup and restore in LOS 17.1 with encyption = ok
sant514 said:
With TWRP 3.3.1-HH.R.4 nanroid backup and restore in LOS 14.1 with encyption = ok
With TWRP 3.3.1-HH.R.4 nanroid backup and restore in LOS 17.1 with encyption = ok
Click to expand...
Click to collapse
Can u tell me which build of LOS 17.1 have u used for these tests?
Los 17.1 28-02-2020
sant514 said:
Los 17.1 28-02-2020
Click to expand...
Click to collapse
Thanks! U just confirmed that LOS 17.1 could not be restored due to selinux denials. Some days ago i've updated sepolicies and now everything works.
@dahawthorne, FYI
Excellent news - thank you.
And also a relief to find that I wasn't just being an idiot...
I see "E:Unable to decrypt FBE device" when flashing in TWRP.
Should I just disregard this message?
smsmasters said:
I see "E:Unable to decrypt FBE device" when flashing in TWRP.
Should I just disregard this message?
Click to expand...
Click to collapse
Just ignore it.
Our device doesn't support FBE (file based encryption). So this error doesn't affect our device at all.
Since I was the one to mention my problem with restoring a TWRP image, I think I should report that, as z3DD3r stated above, TWRP HH 4 does indeed work fine in making and restoring backups. I took a backup yesterday and restored it this morning; no wipe, just a straight recovery, and it all went through in less than two minutes.
Thanks for all your work, z3DD3r. It's great to have bleeding-edge software on such an old device.
Hello @z3DD3r , I've been working on a ship for the last couple of months, so missed some things.
I'm using the first original twrp-3.3.1-HH-hammerhead version you shared in the telegram group, but now I found this thread with newer versions.
Just wanted to double check if it's okay to update straight from that original HH version (ALREADY REPARTED) to the lates HH.R.4 without any problems.
z3DD3r said:
How to revert back to stock /system size and stock partitions map:
- Launch HH.R version of TWRP
- Open terminal (TWRP -> Advanced -> Terminal)
- Type hh_repart -r
- Wait until your phone reboots
- Flash official TWRP or HH.S version of TWRP! Don't ignore this step!
Click to expand...
Click to collapse
And just out of curiosity, cause I'm not planning on reverting to stock partitions. Why is it so important to flash official or HH.S version after reverting?
What is the difference between stock and HH.S.4 then?
Thanks for putting your time and efforts in to keeping this device alive!
TomiLynch said:
Hello @z3DD3r , I've been working on a ship for the last couple of months, so missed some things.
I'm using the first original twrp-3.3.1-HH-hammerhead version you shared in the telegram group, but now I found this thread with newer versions.
Just wanted to double check if it's okay to update straight from that original HH version (ALREADY REPARTED) to the lates HH.R.4 without any problems.
Click to expand...
Click to collapse
twrp-3.3.1-HH-hammerhead and TWRP HH.R uses the same script for repartition. So, yes, it is okay to flash HH.R over the twrp-3.3.1-HH-hammerhead.
TomiLynch said:
And just out of curiosity, cause I'm not planning on reverting to stock partitions. Why is it so important to flash official or HH.S version after reverting?
What is the difference between stock and HH.S.4 then?
Thanks for putting your time and efforts in to keeping this device alive!
Click to expand...
Click to collapse
Because TWRP includes size of system partition. This size should match the size of system partition on device. Otherwise bad things can happen...
Code:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
LineageOS Modded is a free, community built, aftermarket firmware distribution of Android 11 (R), which is designed to increase performance and reliability over stock Android for your device.
LineageOS Modded is based on the Android Open Source Project and LineageOS with extra contributions from many people within the Android community.
All the source code for LineageOS Modded is available in the LineageOS Modded Github repo.
What's working?
Everything as far as I can tell...
Installation
1. Boot into twrp
2. Advanced -> ADB Sideload -> Swipe
3. adb sideload copy-partitions.zip
4. Go back into sideload mode
5. adb sideload lineage.zip
6. Wipe Data
7. Reboot to bootloader
8. fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img
Downloads: http://1pwn.ixmoe.com/android/ginna/los-18.1/lineage-18.1-20210621-HOMEMADE-ginna.zip
Notes
This ROM comes with Google Apps!
This ROM comes with Customizations that are not apart of LineageOS
Sources: https://github.com/motoe7
Credits: @electimon, @RohanHasabe8, betaxab
Jan 27 2021: Fix Safetynet, fix touch issues, fix some other issues
Jan 28 2021: Fix PIP mode
Jan 30 2021: Fix Hotspot
June 2 2021: Fix touch for ginna models with the new panel
June 15 2021: Fix touch for focaltech panels
June 20 2021: June Patch, fix safetynet and other little stuff
Awesome, been waiting for this, thanks very much! Had some errors while loading copy-partitions.zip but the image flashed and seems to be working well. Look forward to future versions with SELinux enforcing and also without gapps (but maybe that's not likely with no opengapps for 11?)
Would be great if there was a way to remove the obtrusive "device can't be trusted" message at boot. It can be just as trusted as my desktop PC ffs. At least moto allows the bootloader unlock without much trouble.
anthony.d said:
Awesome, been waiting for this, thanks very much! Had some errors while loading copy-partitions.zip but the image flashed and seems to be working well. Look forward to future versions with SELinux enforcing and also without gapps (but maybe that's not likely with no opengapps for 11?)
Would be great if there was a way to remove the obtrusive "device can't be trusted" message at boot. It can be just as trusted as my desktop PC ffs. At least moto allows the bootloader unlock without much trouble.
Click to expand...
Click to collapse
hi, selinux is enforcing also there will be no version without gapps sorry
Electimon said:
hi, selinux is enforcing also there will be no version without gapps sorry
Click to expand...
Click to collapse
No worries about the gapps, i'm grateful to have a lineage rom for this device.
I tried flashing again. Pardon if the details below are excessive, I don't fully understand the process, and the dual-slice device config. Here's what happened:
copy-partitions gets to 47%, then fails with the following error:
Partition vendor_a
dd: /dev/block/dm-4: write error: No space left on device
installed lineage again, this time went to slot B. rebooted back into TWRP and tried copy-partitions again (to see if it was different after lineage had been installed in both slots) and this time it succeeded. Installed lineage again, this time to slot A. Wiped the device, rebooted, and I still get the selinux error. If it's relevant, the device model is XT2052-1.
Also want to add: I applied disable-verity both times, and cmd line output indicated writing to vbmeta_a and vbmeta_b.
weird, how are you checking for enforcing?
android_device_motorola_ginna/BoardConfig.mk at efea8269c9a6a232d8ba38b0629a61eb590b2db5 · motoe7/android_device_motorola_ginna
Contribute to motoe7/android_device_motorola_ginna development by creating an account on GitHub.
github.com
you can see here that permissive is commented out, the rom is enforcing.
I installed the rom mainly as a reference against the no speaker (except in calls) issue I'm having with 17.1. Also I'll note there the issue isn't jacksensing as I had guessed. A soundfile playback autopauses on headphone removal. With 18.1 here I do get speaker output, however one bug I noticed for me (boostmobile-sku:mot20526anb/xt2052-6) (also present in 0206 17.1) is that in-call volume adjust doesn't work. The indicator moves, but the actual volume does not. I'll send some logcats. Seems to be stuck at what is probably supposed to be max volume.
Electimon said:
there will be no version without gapps sorry
Click to expand...
Click to collapse
Is there a standard/safe way to uninstall gapps via scripted adb commands immediately after install? I experimented with a crude attempted pm uninstall/disable/disable-user of all com.google.* packages but was not too surprised when the result failed to boot past the lineageos boot animation.
Cyb3rSl4v3 said:
Is there a standard/safe way to uninstall gapps via scripted adb commands immediately after install? I experimented with a crude attempted pm uninstall/disable/disable-user of all com.google.* packages but was not too surprised when the result failed to boot past the lineageos boot animation.
Click to expand...
Click to collapse
I'm unsure of that
I finally figured out how to build 18.1 on my 8g-ram system such that I don't have to worry about uninstalling gapps (amongst other motivations). I'll post details once I've done another less manual build. The trickiest part was that the 17.1 workaround of setting JAVA_TOOL_OPTIONS/_JAVA_OPTIONS to -Xmx6g wasn't getting used by metalava in 18.1. I ended up editing the last line of out/soong/host/linux-x86/bin/metalava and putting it in there which finally worked. Perhaps tools/metalava/gradle.properties is the right place. My first pass doesn't have carrier data/call service working, but that may be because I did something with TimeService to get it to compile. In any event, I think the 16g minimum warning from the build system is more than a bit confusing combined with the metalava java heap issues. I may try a 4g-ram build sometime just for amusement... It just seemed inconceivable that there really was a 16g-ram requirement. I know even phones come with 16g these days, but still. Of course my hope is to see a cheap phone of mine self-hosting one of these days. Perhaps with some high end microsd card or an otg drive for swap partition and build tree...
Cyb3rSl4v3 said:
I finally figured out how to build 18.1 on my 8g-ram system [...] The trickiest part was that the 17.1 workaround of setting JAVA_TOOL_OPTIONS/_JAVA_OPTIONS to -Xmx6g wasn't getting used by metalava in 18.1. I ended up editing the last line of out/soong/host/linux-x86/bin/metalava and putting it in there which finally worked. Perhaps tools/metalava/gradle.properties is the right place.
Click to expand...
Click to collapse
I haven't quite done a fully automated build yet, but tools/metalava/gradle.properties didn't work for me. Then I found that the metalava (wrapper) script was build/soong/scripts/jar-wrapper.sh, and adding a next to last line of-- javaOpts+=("-Xmx6g") --seems to work. I also now better understand device/motorola/ginna/lineage.dependencies and seem to be able to reproduce this image sans gapps (though an selinux issue i haven't looked too much at yet). I may focus more on 17.1 until 18.1 becomes more generally official. I also seem to be getting occasional sigsegvs with jre/metalava dumping hs_err_pid*.logs. However thus far a simple rerun of brunch/ginna has never reproduced the problem.
Camera apps have quite a lag related to camera apiv2. Haven't had time to debug, but Open Camera works perfect as it defaults to the old api.
Do we have system read/write on these builds and does magisk work?
Idk about system r/w, but Magisk works fine. This is also a really good rom. Stable and nearly everything works.
fddm said:
Idk about system r/w, but Magisk works fine. This is also a really good rom. Stable and nearly everything works.
Click to expand...
Click to collapse
I checked, it has system rw. I can't believe how fast my LTE speeds are too. 7-10MBs vs 50kbs on stock. The only thing holding me back is no full screen toggle for apps, and the in call volume is stuck at the maximum at all times. Soon as those get fixed I'm running this 24/7.
2+ months now with 18.1 on my daily driver.
No hardware issues.
Ofox recovery.
Magisk 21.4 thru the latest canary build have worked as far as I can tell.
No volume troubles.
Can mount system RW.
My only setback is that I don't have access to around 9Gb on /data and /sdcard, including /sdcard/Android/obb
I can set perms any way in terminal and in recovery terminal 0777, 0655, etc., but upon reboot, I cannot read or write.
Can read and write to /system and /system_root, no problem.
This is possibly due to me forgetting to wipe encrypted /data after first flash? I wiped after first boot, no change.
Then, started the flash process from scratch and wiped before first boot, but must have missed something.
The file and folder names are not random characters.
One of those things I thought will work out when I get around to it, but now just found my pics are being saved to a folder in the mystery space, and I need to place a .zip in *./obb.
Im learning, A/B is new to me.
Maybe my mistake will help someone when I find a solution.
I am open to suggestions, lessons, and any other info, even if I should already know it.
I will report when something changes.
RaceyMcRacerson said:
2+ months now with 18.1 on my daily driver.
No hardware issues.
Ofox recovery.
Magisk 21.4 thru the latest canary build have worked as far as I can tell.
No volume troubles.
Can mount system RW.
My only setback is that I don't have access to around 9Gb on /data and /sdcard, including /sdcard/Android/obb
I can set perms any way in terminal and in recovery terminal 0777, 0655, etc., but upon reboot, I cannot read or write.
Can read and write to /system and /system_root, no problem.
This is possibly due to me forgetting to wipe encrypted /data after first flash? I wiped after first boot, no change.
Then, started the flash process from scratch and wiped before first boot, but must have missed something.
The file and folder names are not random characters.
One of those things I thought will work out when I get around to it, but now just found my pics are being saved to a folder in the mystery space, and I need to place a .zip in *./obb.
Im learning, A/B is new to me.
Maybe my mistake will help someone when I find a solution.
I am open to suggestions, lessons, and any other info, even if I should already know it.
I will report when something changes.
Click to expand...
Click to collapse
I never had this issue so I'm guessing it's something to do with encryption. I would try clean flashing LOS to both slots then formatting data using the type "yes" option to remove encryption. Are you using adoptable storage by chance?
How can I install this rom via recovery, I have never used side load. Why is it not booting? What is wrong. I flashed rom in slot B with twrp in slot A sorry still a little new with this device. But regardless it is not booting whatsoever and I am confused as to why
Mr.Conkel said:
How can I install this rom via recovery, I have never used side load. Why is it not booting? What is wrong. I flashed rom in slot B with twrp in slot A sorry still a little new with this device. But regardless it is not booting whatsoever and I am confused as to why
Click to expand...
Click to collapse
Flash it to both slots and format data before booting up.
Spaceminer said:
Flash it to both slots and format data before booting up.
Click to expand...
Click to collapse
Is there any benefit of having it flashed to both? Cause I did get it working. There's not currently anything on slotB
Mr.Conkel said:
Is there any benefit of having it flashed to both? Cause I did get it working. There's not currently anything on slotB
Click to expand...
Click to collapse
Not that I'm aware of. I've never got it to boot without flashing to both slots though. Did you use the zip, or fastbootd images?
As soon as I updated to LineageOS 19.1 on my OnePlus 5T (dumpling), Lookout reported two I-think-built-into-LineageOS packages as potential threats:
com.mtg.gmssettingsprovideroverlay
com.mtg.gmsoverlay
I believe that these are built-in to LineageOS.
Lookout complaints about them because they are "signed by a private key that is publicly known or shared between multiple developers".
That actually is a pretty good reason to mark the packages as a potential risk.
Searching for these two package names, I find nothing.
What are they? Are they properly part of LineageOS 19.1?
Are they needed?
Why are they signed by a private key which Lookout thinks is, in effect, compromised?
thanks,
Hm. That said, I opened a root adb shell, did:
# find / -name "*gmssettingsprovideroverlay*" 2>/dev/null
.. and only came up with empty directories. With the single exception of:
./config/sdcardfs/com.mtg.gmssettingsprovideroverlay
.. which contains:
"appid", ls -l shows 4096 bytes but contains only the short text "(10014"
"clear_userid", ls -l shows again 4096 bytes, the file is write-only (--w--w--w-)
excluded_userids, again 4096 bytes, file contains just a newline \n
Identical, for gmsoverlay (with appid containing "10044").
I used "od -bc" and even "dd if=... bs=4096 count=1 ..." on both of the appid files, and although they show up in ls -l output as 4096 bytes, they do seem to be only these short text files - no NUL padding or anything else, without going to disk analysis tools (which are so far in my past, and I never used on Android anyway, that I wouldn't know how to do it anymore today).
(Please forgive my ignorance) How would I look to see whether in fact these two packages are even there (I'd expected to find an .apk or some code) vs. false detections by "Lookout"?
thanks,
Lookout support has been very forthcoming. Unfortunately, for things-installed-as-part-of-the-system Lookout will only indicate the presence, not the actual location.
I searched (in adb root mode) in /data/app, /system/app, and /data/priv-app, and I was able to identify every package. Nothing had *gms* in the name, and nothing was left after I sifted for all packages to see that they are known.
Does nobody else run Lookout on LineageOS 19.1 (on a recent OnePlus device)?
If you do, do you get these warnings from Lookout?
I worry about what would happen if I tell Lookout to remove these unknown things. I don't particularly want to brick and have to re-setup my device...
thanks,
I've had the same experience with Lookout on LineageOS 19.1, so I would like to know if this is resolved and what the recommended action is.
I made no further progress.
Sorry to bring this thread back but I have the same issue with Lookout albeit on a Pixel 3 running Lineage OS 19.1
When installing Lineage did you include MindTheGapps? I believe the issue lies with them as can be found here https://gitlab.com/MindTheGapps/vendor_gapps/-/issues/10
Above link also links back to this post
Thanks sjoyce666 -- yes, I do use MindTheGapps. Thanks for the gitlab posting; I've added a comment there supporting it.
Have you tried using a different GApps package to see if Lookout finds the same error?
I haven't; I'm not clear whether that can be done without a clean flash, which I want to avoid.
Does it work to re-flash the current LineageOS plus a different GApps package, without causing conflict/ corruption due to the already existing MindTheGapps package?
And, anyway, the LineageOS installation instructions for my device (dumpling, OnePlus 5T) only lists MindTheGapps; what other Google Apps package might I try?
thanks.
sjoyce666 said:
Have you tried using a different GApps package to see if Lookout finds the same error?
Click to expand...
Click to collapse
libove said:
I haven't; I'm not clear whether that can be done without a clean flash, which I want to avoid.
Does it work to re-flash the current LineageOS plus a different GApps package, without causing conflict/ corruption due to the already existing MindTheGapps package?
And, anyway, the LineageOS installation instructions for my device (dumpling, OnePlus 5T) only lists MindTheGapps; what other Google Apps package might I try?
thanks.
Click to expand...
Click to collapse
I don't think another GApps can be loaded without a clean flash as you cannot load GApps after Lineage has first booted so there must be some setup going on during first boot
I also don't know what other GApps package to try, there are plenty out there but I know Lineage does recommend MindTheGapps which is why I also used that one
Hopefully MindTheGapps will have a resolution but I would guess as the source code is posted online Lookout may have found this and decided any keys used are public because they are available to view on GitLab
Sorry for my English. I have Xiaomi mi8 with last LineageOS. Into root folder of phone I put zip gapps file. But when I turn my phone to fastboot and than to TWRP, I can not find my zip file with gapps. The structure of folders is different than when phone is connected to PC. Maybe you know what to do with it please?
As far as I remember you can/must select the storage, including sdcard (which I prefer to use).
PS: Ahoi
Phone does not have external storage card extension. No, prostě když ten telefon připojím k počítači, je tam určitá struktura složek. nahraju tam zip. Pak dám fastboot, dostanu se do TWRP a dám install a už tam je úplně jiné složení složek a zip nemůžu najít
oh, actually I know only 3 czech words: ahoi, knedliki and staropramen
anyway, in TWRP you can select the storage (bottom left, i think). (gtranslate: v TWRP si můžete vybrat úložiště (myslím vlevo dole).)
I know I can select the storage. But, it is impossible to find my zip file The structure of folders is diffrent than the structure I can see when phone is connected to PC for file transfer
A) Maybe a fast workaround: Use an USB OTG adapter and plug-in some USB stick with the files?
OR
B) In modern Android, there are several partitions and my guess is, that you have the files on another.
So you could study some search results for "android partition layout" like p.e. https://source.android.com/docs/core/architecture/bootloader/partitions/system-as-root
FRQD75 said:
A) Maybe a fast workaround: Use an USB OTG adapter and plug-in some USB stick with the files?
OR
B) In modern Android, there are several partitions and my guess is, that you have the files on another.
So you could study some search results for "android partition layout" like p.e. https://source.android.com/docs/core/architecture/bootloader/partitions/system-as-root
Click to expand...
Click to collapse
I will try it and inform you here I have to order usb otg. Thanks
OK, I installedMindTheGapps-12.1.0-arm64-20220605_112439.zipfrom USB otg adapter. But Gapps are falling. They are in phone, but I can not start them.
Hello guys,
I believe that I faced a similar case.
I am using MI8 pro, and I installed lineageos 20 with mindthegapps for Android 13. The Google services keep stopping.
Then I tried lineageos 19 with mindgapps 12.1 arm64. The same failure is reported.
I am totally confused. I used adb sideload way to install the os image and gapps without interrupt.
Is there any idea in my case?
Regards,
illidanpc said:
Hello guys,
I believe that I faced a similar case.
I am using MI8 pro, and I installed lineageos 20 with mindgapps for Android 13. The Google services keep stopping.
Then I tried lineageos 19 with mindgapps 12.1 arm64. The same failure is reported.
I am totally confused. I used adb sideload way to install the os image and gapps without interrupt.
Is there any idea in my case?
Regards,
Click to expand...
Click to collapse
Today, I tried LiteGapps Nano arm64 13.0 v2.8 official version, based on LineageOS 20. However, it still didn't work on my MI 8 pro. (For the people didn't fimilar with LiteGapps, it's another popular Gapps version, as well. )
But if I only sideload the LineageOS 20, it's perfect running.
So the issue could be related with the compatible of Gapps.
illidanpc said:
Today, I tried LiteGapps Nano arm64 13.0 v2.8 official version, based on LineageOS 20. However, it still didn't work on my MI 8 pro. (For the people didn't fimilar with LiteGapps, it's another popular Gapps version, as well. )
But if I only sideload the LineageOS 20, it's perfect running.
So the issue could be related with the compatible of Gapps.
Click to expand...
Click to collapse
Today i tried a new gapps named BiTGApps, which works fine with LineageOS20. The url of BiTGApps homepage is bitgapps.github.io. The "works fine" means the google login service in setting menu, and google play works fine. There's no more gapps installed which is a minimal setup, i believed.
I used adb sideload way to install bitgapps, even the powershell terminal shows error, but it seems didn't affect the result.
I hope this one would help you, either.