EskeRahn

https://community.fxtec.com/topic/2075-protective-case-suggestions-and-ideas/?do=findComment&comment=44757

Thanks for the warnings. Too bad so many programs try to 'be smart' and 'know better' to make sure the user gets a bad experience... 😖

Thanks to @Raksura for posting this in another thread, but let me put it here too, for more to see the progress.

Within a few hours hours, I checked before manually installing this too, and I'm a little confused why it was shared as a preview, so shortly before release. I guess something went smoother in the release than expected. 🤗

You got it offered as OTA update without manual download already?

Remember that they are small, so they easily will be pushed aside when a larger customer wants stuff. Hard to fight the giants. Even though they may already be using multiple sources for standard parts, their volumes are so small that doing so for specialised parts, would add heavy surcharges.

Just a hint, by editing the URL you can do a more accurate filtering than through their UI, e.g I have used this: https://www.gsmarena.com/results.php3?nHeightMin=153&nHeightMax=155&nWidthMin=73&nWidthMax=74&nThicknessMin=6&nThicknessMax=8 (whole mm only)

I have no idea... Sorry ADD Moved the Magisk related discussion to the Magisk thread here.

A tiny thing that cause some reboots: When in inverse landscape, the Power-menu is in the same order as in landscape. So when you press the one close to power as usual to do a screen shot - you get a shut down!?!? The icons should be at fixed positions at the fixed bar rotating the icons only, like they already do correctly between portrait and landscape. In Inverse portrait, it fails completely, placing the bar identical to portrait, and thus at the wrong side and in the wrong order... 🙃 This goes for both Lineage and Stock, so tag @Waxberry hoping he sees it

Well we can only guess. Maybe the fix they tried had some unwanted side-effects they want to iron out?

I have also had cases where it did not pull power from a PC-port, I thought it was the magnetic cable that had not been attached properly. When attached to a port offering 5W (or more) I have seen no issues.

AH I think that is how the "too many retries" seems to be handled, just inactive, a warning text would be nice though. Logging on with my password and locking, it works again.

Worked fine for me too, used it directly from the downloads folder.

Well the principle is the same. Handle the physical print first, and then let default android language-layouts (or our own) act upon that. As I read it, they were debating on how close they want to be to the print or the standard. Both has it advantages, and thus followers. I personally think that what is printed should be what we get BUT not as a limit, but as a base. I want say Shift+1 as well as YelAr+1 to give an exclamation point. I expect YelAr and Shift to work as doublets on ALL the yellow prints, except the letter keys (and that is two on qwertY and fifteen on qw

UPDATED: Hi everyone, there is a new OTA update stamped 2020-03-06, offered. This REPLACES the OTA stamped 2020-03-04, that proved to have an error with Safetynet. IF you already updated to the 2020-03-04, you will NOT be offered the 2020-03-06. But both groups will be offered a common OTA, hopefully in the coming week. The two updates contains the same fixes, but the 04 had slightly newer security patches, and that broke Safetynet OLD message on the 2020-03-04 : Hi everyone, @Waxberry has shared a little sneak view of some expected to be in t

I think the idea @tdm is using is to handle which physical keyboard-print we got first, mapping either to be usable by the standard android language files on top. This should mean that there will be no hard need for additional mapping for normal text and the most ordinary symbols. We MIGHT want some additional mapping for extra symbols etc, but that same mapping would then also work on any other qwerty-phone, and not be Pro1 specific (nor specific to qwertY or qwertZ) That is, if you want a special symbol pressing say Shift+Ctrl+Alt+Sym+Q you would get that no matter where the Q key

Odd, works for fingerprints here ???

Thanks! It works perfect! 😁 Especially the last one I bet will help those not using a case. Would it be possible to not count the 2secs from last registered attempt but from last sensor-touch? That is if I repeatedly press (or even hold) a wrong finger/hand-part at the sensor, it should be ignored, until I leave it free for at least 2s, and then activate it again.

You should include the var= part of an ebay-link ved multiple items, so we can see the right one, e.g. https://www.ebay.com/itm/233460908295?var=533070924751 The easiest way to get it is to put the right variant in the basket, copy the link, and remove it from the basket again. Or if bought from the order list. Are you sure about the first link BTW? I see no "P20 Pro"...

Well of course guessing, but seems rather likely that they work at an office, and not all with the option to work from home. Of course we could be lucky that this is in an area of China not yet affected. But not that likely.

Kind of you to offer, but it seems a bit odd to make a parallel build. If you got the applicable fixes it would make more sense to have F(x)tec implement them. Though I obviously do not know how close/far we are from a new OTA update, with the current COVID19 situation.

Suggestions 1) on the first one. I would suggest to immediately turn screen and touch sensing off BUT do not LOCK the device until the specified time-out Similar to Settings, Security&Location, Screen lock, Automatically Lock PERHAPS doing some pulsing with the notification LED to warn that it is not yet locked. 2) Why not offer an option to lock on keyboard close. Some of us are used to that from ancient devices. (I doubt I would use it though, but others in the forum have been asking for it) I do not quite get the four filters. Especially the

I believe it is not limited to a weak/failing signal, but combined with the bands relevant for the carrier. As more of us would see it if it was just the lost signal.

I would expand that to Option to disallow screen on as well as unlocking with fingerprint if the hall sensor detects closed.

When I use Finqwerty for qwertY Danish, I see the same on "2" BUT it works fine on "P" (giving P resp /) and "L" but not en neighbouring "Å" and "Æ" with YelArr. Also both Sh+YelArr+3 and Ctrl+YelArr+3 gives nothing rather than £ on lineage ... So I guess we would need a special variant of the FinQwerty maps for the approach this lineage implementation uses... Note that if you check with e.g. "Keyevent display", Pressing Fn does not return a code in it self on this Lineage.