EskeRahn

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.

https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_FUNCTION

In my book it always raises suspicion when a very simple thing comes in a large package I immediately think: Hey is this compiled on an infected PC and used as a mule by some malware? And I'm especially cautious/suspicious when it is an app that (for good reasons) needs high privileges. So would be nice if you could dig into the "Why". 🙂

Just curious. Does this include some library, or how does this end up at 1918KB ? Browsing through the source even the small images in various resolutions could not get it anyway near (the source adds up to 1/10th).

He he, well I would rather have @Waxberry or @Erik do that.... AND it should have a 'secret' part we as users could not see. E.g. the priority of each bug/wish. And any known bugs no users have stumbled into yet, that they hope to fix before the public even know it existed. It is common practise on security bugs to not tell about them before they are fixed.

We really should have somewhere offical... We already got this unofficial one: https://docs.google.com/spreadsheets/d/15uE12Yv5nMvIF42U33cY5FQoF6M66QIn00cC876uf7Y/edit#gid=0

Yes they are identical, that is why @Anssi Hannula starts his qwertZ-files (e.g.this) by mapping. For image, see e.g. here ...That they are identical is actually an issue when setting up a new device (WiFi and account credentials), so we need to use the fake keyboard, as the real keyboard acts as the shifted until you get a chance to tell the system that it is the qwertZ. See also this

They are electrically identical, the only difference is the print, so your app will work identical on both. So you can test if you would like to (though the print will obviously not match when tested on a qwertY device) You can see the two stock prints described at the top here

Nice. I too would like to find a good one in leather. On the glue half part, I think it should be mentioned that For those using the back camera and/or LED a lot, it is recommendable to cut a hole, and perhaps glue the whole part (like you did). For those using it less, keeping it un-cut gives a better camera protection, at the price of needing to fold it all the way open to use the camera/LED. I like you idea of using a better inner bumper case, though to me that would be overkill The best one I've found (so far) isn't real leather either. I have bought

Yes that was tricky too but once you get it right it works flawlesly. I tried to make a little help-file, to show at 100%... ADD Sigh, the forum shrinks the image ... Here the full file: https://eskerahn.dk/wp-content/uploads/2020/03/Pro1_Hall_Sensor_Top.png It is roughly 300 pixel from the top and 200 from the Right (refferenced in portrait) Note that the orientation of the magnet matters, so you might need to turn it around back to front

That you only get half, has the benefit that you can investigate the detail of the fit to the curvature towards the side edges, and how the 'lip' is grabbing the edge. For the same reason you could consider cutting the part you already made in two, to see how good it fits the end-profile.

Interesting! Just a hint on the hole for fingerprint. You should give it slanted edges, otherwise it will be hard to get to.

Very interesting, thanks! I tag @Waxberry to make sure he sees this, so It can be forwarded to the right people. 🙂 Especially interesting that they even got a workaround..

BTW $550 is really a bargain price, I bet it will not be up for long. Had someone done the same in Europe with a qwertZ model, I would be VERY tempted to buy it as a spare.

So sad. Hope to see you back.

Too bad you can not get it working. Some US carriers require some trickery. Have you seen this thread?

Oh indeed, specially newer Bluetooth versions are more lenient, but for those of us not using it, it is still waste of battery, and hence stamina. I'm not saying that all radios should be off, just those that aren't in use and isn't needed.

Maybe this code sample from here can be modified to a more general list, of course of different type and the firstOrNull should obviously be replaced with some loop private lateinit var sensorManager: SensorManager private var mSensor: Sensor? = null ... sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager if (sensorManager.getDefaultSensor(Sensor.TYPE_GRAVITY) != null) { val gravSensors: List<Sensor> = sensorManager.getSensorList(Sensor.TYPE_GRAVITY) // Use the version 3 gravity sensor. mSensor = gravSensors.firstOrNull { it.vendor.contains("Googl

I know nothing on the interior of Android, but could the API return an ARRAY with values for the two sensors?