EskeRahn

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?

The list in Quicom's "Device Info" seems longer (50 sensors), But it does not seem to appear there either. It could be the one five from the bottom with the long name "BU52061NVX ROHM_HALL_EFFECT", but it does not show the readout from the sensor. So hard to say if that is the one See this

I know what the proximity sensor is ... BUT they just MIGHT be exposing these two Hall sensors as "TYPE_PROXIMITY" (Note: TYPE), The reason to believe so is the binary type output we see in the FactoryKit test-program. And if you are looking for it as a TYPE_MAGNETIC_FIELD sensor, no wonder you can not find it.

Ah, that made more sense.... Most likely it is handled as a proximity sensor, And if we are unlucky it might not be marked for wake up. https://developer.android.com/reference/android/hardware/Sensor#TYPE_PROXIMITY https://developer.android.com/reference/android/hardware/Sensor#isWakeUpSensor() But as the other Hall sensor IS clearly able to wake up the device, it seems unlikely that they are not both.

It is easy to find, it is near the end of the volume rocker. I have posted stuff showing the whereabouts above.

The same author also have a "Transparent CPU Monitor", that can show CPU and GPU as a transparent layer. That might be helpful in debugging?

I just ran it again WITH the tick box to include the temperature, and note on the first how the temperature of ONE of the cores is sky-rocketting in the first minute, and stays up during the entire test, while the other cores are at a more moderate temperature. They all start out at around 20 (it was placed at a table at a room temperature of 21) Also note that I have been EVIL, I did NOT take it out of the flip-case, so it did NOT have the cooling from the exterior it is designed to have.

I just tried the first on a S8- (exynos, so not the same) and the Pro1. And even throttled it is higher than my S8- before throttling. (The Pro1 was disturbed by a call I did not answer during the test, the red line)

Well though you might not care on the battery stamina, I assume you are interested in the battery life - even if the device are not glued together. Heating the device too much kills the battery. (That is the exact reason why we -as you wisely do- should avoid fast charging in normal daily usage, and only use it when we are in a hurry)

Well if you quick-charge it you certainly get it extensively heated, so if you get a low FPS rate then, but a high rate when it is cold, that should give a pattern. You could even try to operate it on something cold, and see if that helps it. If it does, your intuition on throttling is right. Be careful not to take something TOO cold, we do not want risking condensation of water vapour from the air inside the device.

Hmm, that is odd. No matter how good or bad, we would expect it to be consistent. Could something be running in the background taking the resources? Try something like "Android Assistant", and click the "Processes" tab, and perhaps kill (=stop) irrelevant stuff, and see if you can get more consistent results. Perhaps try something that works off line, and put it in Aeroplane mode, to isolate.

Well good that you reported it, and the more details the better. I'm not in anyway saying that they by optimisation wenot could extra out of the hardware. But I think they are more than busy with fixing bugs & malfunctions, so the easier we can make it for them to narrow down where there is an optimisation needed, the more likely it is to be implemented. It could be as simple as some code left in a debug mode somewhere, that uses/wastes time on logging, or it could be a complex thing needed. And worst case it is a limitation with the screen hardware/interface. So the more it

Note this is open camera, and I see similar on both Stock and LOS. I'm pretty sure there is BUG in the camera API, so when OC tries to stitch things together we get weird Halo's. HDR with OC works just fine on other phones, so I'm pretty sure it is a parameter issue on one (or both) the images that are to be stitched. My GUESS is that something is handled as linear that ought to be handled logaritmic or vice versa.... e.g what should be 10% longer exposure is handled as 2^10%=7% The snapdragon-camera-app does NOT have this on HDR. So it either access the camera directly, and not through t

Those mushrooms clearly did not do you any good... 🤢 But on a more serious note, I tried to take an extreme HDR-image with both LOS and stock, and in stock I got the below (well here a cropped and reduced version of it). Note the lime-green halo on the flames.

...Stop eating whatever you are eating immediately... 🤣

Just a random case for another new device, and this is even just an evolution over what they already got.... https://www.dpreview.com/news/4862735124/some-galaxy-s20-ultra-smartphone-reviewers-report-multiple-camera-issues

Yup. As I usually say: Every £1M spent on a device selling 1M pieces is just £1 each, but for a device selling 10K it would be £100 each... And this goes for development and optimising just the same... And this is also why we should not expect massive ad campaigns at e.g. super bowl... So everybody should spread the word to everybody they think might be just a little bit interested, or might know one that is... The best chance of this being a success is if the info on it spreads viral.

Do we even know how their workflow on service requests are supposed to work? I would not expect any reaction that fast either. As Eric said everyone is still doing everything, and most likely that means they have piles of work each...

Different tools reports slightly different. They say MSM8998 835, but the max frequency is reported at 2.46GHz by CPU- and as 1.9GHz by "Device Info" (Quixon). (ADD: they report the same on Lineage and on Stock Pie)

Though there is a common rubber mat over everything, and clicking VERY close to a border with a nail, can click the neighbouring key also. Tried to lift up the separator grid with a nail and hold it with a toothpick: So optical illusion that the e-ink moves with the key...

I yesterday got the old SCH-U750 aka Zeal aka Alias 2. Very interesting. There are little movement of each key, but to my surprise it looks like the e-ink move with the key, so it is not just a transparent mat on top of a common e-ink display, But it looks like it is 42 individual matrix e-ink displays! And a warning to @abielins: The below is AFTER a thorough cleaning attempt. You do NOT want to know how it looked before. I believe it might have been an entire eco-system....