EskeRahn

We got a long thread filled with various suggestions here I got my own with links to where I got the different ones i experimented with here. You can modify most cases for a "Huawei p20 pro" with a small pair of scissors in a few minutes.

For widgets this should include allowing different dimensions used in the two directions. E.g. You might want a widget in landscape to be wider than what is possible in portrait.

We better tag @tdm here, he knows a LOT more about this than I do.

As described above, this really is the viewer not being in compliance with the jpeg standard ignoring the EXIF rotation flag.

Just for generel info. When rotating an image, until some years ago, the image information was 'resampled' to give the wanted direction. BUT there is also a FLAG in the EXIF metadata, telling if the image is to be rotated 0°, 90°, 180° or 270° Unfortunately still not all viewers/handlers respects this!! So in one context a file may show correct, and in another in the native original data's orientation, that is: rotated compared to what was intended. The purpose of this flag is to make rotation fast and easy, while keeping all image information. The price is that the image is to be rotat

I just did a factory reset a few days ago, and was able to skip

It can take a VERY long time to get the very first fix. Try to leave it outside for say ten minutes, and see if that helps. But Lineage DO seem to use fewer satellite-systems, see also the discussion here a month ago.

I think the optimal would be if we could arrange things independently for the two directions BUT when adding a new item in one direction it also tries as best it can to add it in the other, but allows us to rearrange independently and even to remove for one direction only. The automatic system could then have different 'modes' like the 'two-half' approach, 'keep centre and corners', 'start filling bottom up' and what ever other algoritms that can be thought up.

You are welcome. And no wiki I'm aware of.

It seems to always do this, did on all the test/images too, so quite normal. Actually the gaps also 'stops' at 47% but is so much faster that we usually do not notice. (I wonder why they did not choose to stop at 42 😁😇)

This sounds really bad! Let us tag @Erik so he can find out what has gone wrong.

Also try and 'dial' *#*#4636#*#* (4636=INFO) and select Phone1 Information, and double check that "Mobile Radio Power" is ON. You could generally compare the settings for slot 1 and 2.

For the first time in at the least a year I had it too this morning. And looking at the logcat it could be related to WiFi. I see entries like these before and not after the crash 08-24 07:48:21.605 1668 2065 E AndroidRuntime: FATAL EXCEPTION: LocaleTracker 08-24 07:48:21.605 1668 2065 E AndroidRuntime: Process: com.android.phone, PID: 1668 08-24 07:48:21.605 1668 2065 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.net.wifi.WifiManager.setCountryCode(java.lang.String)' on a null object reference 08-24 07:48:21.605 1668 2065 E Andr

Indeed this is rather limited, but a convenient usage of MTP to INCREMENTAL copying files can be found here.

Indeed. Had it been easy to spot, they would most likely have fixed it. If it 'only' happens as seldom as in the order of days or even week it will be very hard to reproduce systematically, no matter what you do.

You do not need a sim to do emergency calls. And I did disconnect immediately when I accidentally triggered it - and yet got contacted to assure that I was OK....

Obviously the bug should be fixed on the Pro1, but you might help them in testing if this theory has anything to do with reality. It could be other things that also affects it so even if they bought the exact same router they just might not see the same bug. And thus would not find the bug pestering you. The more it can be narrowed down, the easier it will be to find and fix.

An interesting theory if SON is triggering this bug! Could you (temporarily) set them as two independent networks, and see if the Pro1 can work with both without the random boots? And if that works double check that the bug reappears by setting your router back to using SON.

Great! ... But skip the emergency test.... It will call your local emergency with no warning on click....

On stock this (still) requires you to be careful how you grab the device, to avoid accidental triggering, and the annoying "Too many retries". OR on the contrary be sure to register the fingerprint of the finger touching when grabbing to deliberately unlock when picking it up from the table/pocket. It should be said that this problem is in reality eliminated if you use some sort of case. And 100% eliminated if a flip case opening to the right behind the screen is used ('Japanese' style book).

It is simpler to just add some pieces of 0.5-1mm thick adhesive rubber/felt without removing anything.

Interesting. Though my experience with the stiff types are a poor fit. The reason is that the back of the Pro1 is not just flat but slanted towards the sides.

Stock is even pickier on VoLTE it seems... https://community.fxtec.com/topic/3055-volte-voice-over-4g-data/

Good to know that it is not a thing specific to the Pro1, but a more general issue.