Temporarily solved by switching to another unofficial app, Facebook Lite. It properly allows choosing photos. It must be an issue with Frost maybe not being updated for Android 13. Was working fine on all A12 GSIs.
[GSI][13] LineageOS 20 TrebleDroid-based
- Thread starter AndyYan
- Start date
Isn't this caused by wifi suspend optimizations?(deleted)
EDIT:
Huawei P10 still WIFI Disconnects after 2 Minutes turning screen off. Checked the logs and found this issue reported 3 years ago:
WiFi disconnects after the screen is turned off · Issue #27 · enesuzun2002/LineageOS-Releases
If I turn off the screen, the wifi connection will be disconnected after a few minutes. Not sure if always, but almost every time This is present in 2020-04-18 and 2020-01-21 Builds. I have SM-G925...github.com
Working workaround:
Activate adb debugging as root in dev options and start adb as root on your pc:
$ abd root
$ adb shell
$ echo 1 > /proc/sys/net/ipv6/conf/wlan0/disable_ipv6
Then WIFI stays connected after you turn the screen off.
EDIT 2:
The workaround i mentioned is just temporary. It works till you reconnect to the WiFi or reboot. Disabling Ipv6 on your router makes it work but then some services might not work for you which rely on IPv6.
Since its TrebleDroid based i tried to install the TrebleDroid Android 13 GSI. In the TrebleDroid GSI the bug is also present. Its not a specific LineageOS problem.
Try
settings put global wifi_suspend_optimizations_enabled 0, and switch wifi off and on.
Thank you for you reply. But sadly this isnt working. The only workaround is deactivating IPv6 right now. But its a bad workaround. Sadly this makes the phone unusable even if the rom is working great. This bug is also present in TrebleDroid which is used as base. The "light" approach isnt booting. I can provide logs but im not able to fix the cause by myself.
@AndyYan , what if I want the functionality like this: https://github.com/LineageOS/android_packages_apps_FlipFlap ?
How it should be added?
Thanks.
How it should be added?
Thanks.
Does anyone else have problems with sending SMS?
Sending messages via RCS is possible without any problems.
The reception works as well. Only sending is not possible.
Sending messages via RCS is possible without any problems.
The reception works as well. Only sending is not possible.
Never had an issue sending texts on this gsi. Just with phone calls consistently not going through in a select few areas. Sounds like a carrier issue. I use the AOSP messaging app, not google's messaging app. Or QKSMS, my fave 3rd party messaging app. No issue with that either, although i'm not sure if it supports RCS.
Thanks for your report on your experience.
Had tried the Google Messages app and also the AOSP SMS app.
Google Carrier Services is also installed.
On an Xperia XA2 with LineageOS 19.1 I was able to send SMS with the same apps and the same SIM card at the same location without any problems.
Where could the error be here?
The ability to send SMS is very important for me.
Had tried the Google Messages app and also the AOSP SMS app.
Google Carrier Services is also installed.
On an Xperia XA2 with LineageOS 19.1 I was able to send SMS with the same apps and the same SIM card at the same location without any problems.
Where could the error be here?
The ability to send SMS is very important for me.
I'm just going to reiterate that it's probably a carrier issue. That would be my personal best guess. Have you checked your APN settings? Maybe they are incorrectly configured.
Yes, they are as recommended by the provider and the same as on the other smartphone via which SMS sending was possible without any problems.
OK. I get it. I misread you. I thought you meant that you were previously on 19.1, but switched to LOS20 and suddenly started having issues. Now I see that you're comparing a current device against another device that was also running an LOS gsi. If it was working on an older LOS gsi on the same phone, but not on 20, that wouldn't make much sense.
I kind of had a similar issue a few months ago, when I swapped my active sim card from an older phone to my Note 20 Ultra (the one I'm using now). This was on the stock ROM, not a gsi. Basically, I got a carrier message saying that my settings for texts/calls/data were incorrect. And it was offering to remotely reprogram my sim card with the correct settings. The message looked legit, so I accepted, and the issues went away immediately.
Unfortunately, I never received such a carrier message.
I have pulled a logcat to see if the cause of the error can be found in it.
These are the locations I would associate the error with:
I have pulled a logcat to see if the cause of the error can be found in it.
These are the locations I would associate the error with:
Code:
01-22 10:47:03.574 5636 16695 E Bugle : SendStatusReceiver: failure in sending message part. partId: 0, partCount: 1, resultCode: 104, errorCode: -1, messageUri: content://sms/7379 {x-message-id:0}
01-22 10:47:03.582 5636 16695 E Bugle : SmsSender: Unexpected sent intent resultCode = 104If it's an issue with GApps (worth testing), install DSU Sideloader. Grab the latest LOS 20 img file that doesn't have GApps. Use the DSU app to install that as a dualboot gsi, then boot into it and test there. You won't lose your current LOS if the results are similar. Just a quick reboot and you're back in. You can install and boot the whole thing in under 10 mins, on a reasonably fast device. But it needs root. Installation via adb is also supported, but I've never tried it that way.
Unfortunately, the logcat isn't very useful in this case, all it's saying is that the message failed to send with the Google app, with a result code of 104. But it doesn't give any real hints of the underlying problem.
There are logcat apps out there that can also check the modem logs, as well as Android's logcats. I think a modem log would be more useful, but it will probably be hard to interpret.
Not many views on your logcat. I checked it myself, couldnt find anything that stood out. Worst case, reflash stock firmware and test there. If it still happens there, then gsis in general can be ruled out as the culprit. Might also be worth getting a replacement sim from your carrier, available for a small one time fee. Or switch to esim, if your device supports it.
Does anybody works Gpay via magisk with safynet fix? when i try to run this only shows for a while and closes.
Not working for me. My local transit authority uses Gpay as a payment option. But it always fails when I try to use it to buy tickets in their app. NFC is enabled, and I've already added a credit card.
I'm rooted with Magisk Delta and have @Displax's modded SN fix installed. All SN checker apps show that I pass. Pokemon go works, my banking app works. But Gpay/Android Wallet apparently doesn't.
Google should stop hating on rooted/unlocked/custom ROMed devices and just let us pay. As long as they get our $, why does it matter? They're greedy, but apparently not greedy enough to not discrimiHATE (intentionally mis-spelled) against us.
Thank you for your help.
Curiously, I tried sending an SMS to a new recipient over the weekend and it worked flawlessly.
With the messages that could not be sent, it can not actually be the receiver, because I could send SMS from the same cell with the same settings and the same SIM card from my other smartphone.
So SMS sending works, but only with certain recipients, while with other devices SMS sending works with all recipients.
I just can not figure it out.
Have you tested with any other non-LOS gsis? If so, same issue? What about testing on stock firmware?
Nearly all gsis use a lot of @phhusson's AOSP source code, it's a good idea to try them as a baseline for troubleshooting.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
3I use a similar approach as what @bpham1 outlined to upgrade the stock base of most of my devices, but please only ever think of attempting it if you're sure you can enter bootloader/recovery with key combo from a hot rebooting state. Even then there's still a minute but real possibility that hot rebooting after flashing stock is different from regular hot rebooting.
For devices where I can't take such risks, I simply stick to a certain stock base until GSIs receive the next major Android update, by then I'd simply start over from a newer stock base.
Also keep close attention on the flashing progress and reboot timing to interrupt it in time, otherwise stock ROM will try to boot and (even if it boots) ruin userdata.2
You're rooted. How big is your data partition/internal storage? 128GB? If you have that much free space available on a PC, then you could connect via USB and make a data partition backup via adb and root access. The native Linux dd command is excellent for copying entire partitions. You would just need to get the exact location/path of your data partition. Then it's just a simple matter of mounting the partition image and extracting data from it. Preferably from a Linux based OS.Thanks for your assessment @AnonVendetta
The thought came to me because I had read elsewhere some time ago that the vendor security patch level could only be raised by updating firmware/vendor and that this was probably possible.
Unfortunately I could not find any info on how to proceed.
Here it is also mentioned that it is possible. But also here is not mentioned how exactly to proceed:
Unfortunately, the people who could provide answers in the subforum of the device no longer seem to be very active.guide PHH GSI FLASH (AOSP 12)
/* * Your warranty is no longer valid, unless...
forum.xda-developers.com
Basically I share your opinion that it would make more sense to flash the latest Sony firmware clean and then flash the GSI together with the modded vbmeta afterwards.
My inhibition at the moment is that I have no TWRP available and both FolderSync, as well as Swift Backup and Titanium Backup do not work. So I can't easily make a clean backup and then just restore it.
Thus, it will be a significantly more complex endeavor....
Also, it would help to know if your data partition is encrypted. Because if so, good luck getting any data from the backup image.
For now, maybe you can just use the free version of Swift and do a local backup only. Copy that to PC for safekeeping.
Instead of FolderSync, copy the folders manually. Again, store the backup on a PC.
I'm surprised to hear that titanium doesn't work. Clear the data of the app and its' addon app. Grant all permissions to both. Make sure you give it root access. And enable usb debugging in developer options. Titanium has never failed me, ever. I like Swift more, but its' explicit dependency on a Google account/play store can potentially make it unreliable when you need it to work.1
Use the vbmeta.img from your stock firmware. Extract the AP tar.md5, in it you will find a vbmeta.img. if it's compressed with lz4, you can use 7-zip zstd to extract the lz4 to an img.
The best way is to patch it manually, instead of using an empty vbmeta. You can do this with a hex editor, I used Frhed. It's portable and doesn't need to be installed.
Open the vbmeta.img file in Frhed. Go to offset 123, write 03 there. Save changes. Then compress the vbmeta.img to vbmeta.tar, flash with Odin, put it in the userdata slot. You will have to factory reset (cleaned cache/data partitions) after flashing vbmeta, so back up important files first.1
I basically see it the same way.
However, it is difficult to find a suitable device for my requirements for which there is also custom ROM support.
What alternatives would there be for a device with (sorted by priority):
- Notification LED on the front
- microSD slot
- display max. 6" / less than 155mm height; OLED, HDR
- NFC
- min 128 GB storage (min UFS 2.1)
- min 4 GB RAM
- fingerprint sensor
- 5G
For my needs, the Sony Xperia 10 III still seems to be the best possible option.
Or are there better suggestions here?1This is how the requirements differ.
I need NFC to describe NFC tags, for the online function of ID cards and for mobile payment.
Notification LEDs are actually installed less and less often. Sony is the only established manufacturer that still uses them.
Nevertheless, it is a very important feature for me.
And as for the display size:
It is important for me that the device can be operated well and safely with one hand and that it fits well in the pocket.
I've already had devices that were too big and bent in my pocket...
Yes, there is the one-hand mode. But why a large display if only a part of it is used anyway? A large device cannot be held better in one-hand mode.
Moreover, I do not have any use cases where I would need a larger display due to clarity or legibility. On the contrary, it could even be smaller.
Smaller displays also tend to consume less battery.
Basically, I am very happy with my Sony Xperia 10 III in combination with the LOS-GSI.
However, there are still the aforementioned small issues that do not work and for which I unfortunately could not find a solution yet.
I don't know if it would be better if I would use a native ROM or TWRP would be available for my device... -
16
MUST-READ BACKGROUND - Android 13 and the two approaches:
As some of you already know, due to various reasons, @phhusson , who kickstarted the GSI trend and committed to it over the years, is backing out from future development - there won't be any AOSP 13+ builds or patches directly from him. He did most of the heavylifting for fixing bugs and implementing features, and selflessly supported more than his AOSP GSIs and more than devices he own. For the situation of GSIs today, we owe him a big thank-you.
Earlier, inspired by @PeterCxy , I took the "light" approach, which starts over from AOSP's generic gsi_* target and adds the minimum amount of fixes needed for my own devices, intentionally leaving many legacy devices behind. For more details about it, visit its own thread.
Meanwhile, a number of existing builders incl. myself have formed the TrebleDroid organization, with PHH himself helping us in technical issues. TD will forward-port PHH's final patches (v415) onto Android 13 and attempt to fix new issues. This is still a new and ongoing process, but if done right, will have compatibility and feature-completion on par with past PHH-based GSIs. This thread contains LOS builds based on TrebleDroid's collective work, which supposedly suits legacy devices, Samsung, etc. better than "light".
Disclaimer:
No flashing instructions will be offered. If you're here in this forum, you should know what you're doing.
No guarantees that everything would work. This is a GSI, bugs are bound to happen.
MUST-READ - reporting bugs:
If you want to report a bug, then you MUST try reproducing on an AOSP reference build of around the same date from TrebleDroid, and ONLY proceed to report here when it's specific to this GSI. This filters out bugs common to all TD-based GSIs, which you should still let me know, but it might not be mine to fix. I might silently ignore your report if you skip this.
Download:
https://sourceforge.net/projects/andyyan-gsi/files/
Scroll down for the naming rules of variants.
Compressed as .xz archives - extract first.
Stuff on GitHub (builders-only):
Most things should be self-explanatory. Not the cleanest code, but should help if you need some clues.
- lineage_build_unified - my unified script for building
- lineage_patches_unified - my unified patches for building
- The LineageOS team
- @phhusson - shaped the treble community, and still takes care of TrebleDroid at a higher level
- @PeterCxy - coded critical fixes such as sysbta
- The TrebleDroid builders
- ...and more
https://paypal.me/AndyCGYan5Updated all variants with January security patches and in sync with TD 20230104. [Insert obligatory backup-and-test warning here]
During my CoV downtime, A13 QPR1 happened and TD-based had a lot of changes as well, which accumulated to this month and I had to update more patches than expected (way more than "Light" - lower maintenance is why I made that in the first place). I might've made oopsies along the way, so I don't feel quite confident about this batch, and you should exercise extra caution.
Some users have reported that securize bootloops their device, and the current "integrally securize" approach means they can't boot up even once. This month I've changed it yet again to "securize on-demand", which is similar to how you securize on PHH/TD-based (a toggle in Treble Settings), but reversible and doesn't require SU.
For new users who are unsure about whether securize might bootloop your device, please turn on USB Debugging and Rooted Debugging below it, and if/when you do hit a bootloop on the next boot, you'll have a rooted ADB shell available to you, from where you can toggle off manually:
For users who are already on a gN build, be sure to toggle it on and reboot right after you update!Code:adb root adb shell setprop persist.sys.phh.securize false adb reboot
Properly fixed exfat for Samsung/Sony, tested on the one Sammy I still own.4Notes:
- I now have a rather taxing day job, and can't devote nearly as much time/effort into this as I did as a student, or even a year ago.
- I now daily-drive "light", so I can't test TD-based builds as extensively as before. For the same reason, I likely won't build/upload any TD-based "personal" build either.
- While most >=A13 GSIs out there are going to be TD-based, some perform better than others - some devs have their own patches that haven't been merged into TD yet. I myself will stay close to TD's raw patchset as much as possible, without picking patches from others left and right. If you find another GSI working better, don't just complain - try to narrow down which ones, and the intersection of them might be an unmerged patch that, if approved, would be merged into TD and benefit all.
- GAPPS builds are offered as-is without guarantees. As a Chinese I can't/won't help with GAPPS/SN issues - please help each other out.
- ADB is intentionally insecure, even on first boot (turned on by default and no authentication needed). GSIs are more fragile compared to device-specific custom ROMs, both on first boot (no-boot issues) and on subsequent boots (after tuning certain Treble settings), and I insist that no-auth ADB is a must-have for debugging and general fail-safe.
- Signature spoofing (MicroG) is supported, but only for priv-apps. This is a security consideration from PHH.
- On *S variants, install PHH-SU and you'll get basic root for apps, good for devices that don't play well with Magisk or when you don't need modules.
- Refer to this post for explanation/workaround of an MediaTek-specific kernel bug that causes no internet.
4
Does it matter? Is it any of your business? Let's keep discussions like this off XDA. Thanks
