The not obfuscated "secret sauce". Take note of NOISE_REDUCTION_MODE set to 1, which doesn't stand for OFF, but FAST. Dear dev, at least steal some non-GPL code for YUV stacking if chroma noise is the same kind of enemy as uhhh, something.

Even mere mortals are absolutely NOT SATISFIED

*low effort posting*

So next time you think of a phone with microSD slot to hold your 1.5TB card, remember: Android Police recommends Galaxy A15 5G 🎉

What's the latest big thing in phone cameras and why gcam hates my phone?

This is a question the owners of recent and upcoming devices may ask if RAW10 isn't exposed by their camera stack. The reason why that occurs is rather simple: stock cameras started moving to sensor modes with higher bit depth by default and going out of your way to support something absolutely not required by CTS doesn't seem necessary.

But why exactly use the higher bit depth?
Well, sensor design and features were improved over the years, while linear ADCs and output remained the norm. This meant that moving on from 10 bits to 14 started to make sense, as long as you actually fit that data inside. The fun thing? Third party apps aren't really getting that milk, they still get 10 bits, just interpolated to 14 already on the sensor.

Why?!
Seamless switching. In particular, taming the sensor mode switching behavior enough to avoid a frame drop or few. To do that, the sensor and ISP need to do exactly what you want at an exact time. The easiest method to achieve it is to duplicate the mode parameters completely: bit depth, virtual line length, virtual frame length and the *exact same frame rate*. So when your logic is to switch HDR sensor modes depending on lighting or literally anything else, you end up with need for matching the bit depth you're operating on, as simple as that. By configuring the sensor to synthetically increase it in normal mode, you have one less thing to worry about in your stock camera app.

And that's too bad for third party apps coded to only be happy with RAW10. Since RAW14 isn't an image format that exists on Android, they have to rely on RAW_SENSOR, a format that always stores 16 bits per pixel, but you're free to hold less.

Back to the topic – yes, it's possible to offer both formats, but as the market is moving and CTS errors aren't going to pop up, some day RAW10 may become a thing of the past. Get ready for the white level of 16383.

And no, that doesn't mean the end of gcam ports as a whole, it only impacts the available algorithms. But since I told you how to force sensor modes few posts ago, think for a bit, you won't necessarily need gcam anymore. 😌

If you have a Revolut account and follow this channel, this most likely applies to you.

Feel free to contact them in any way, but always ask to escalate the matter, as it'll exclude you as a client.
Use the keywords "alternative Android systems" and "device without Google services". Don't go with Graphene as the only example, but skip mentioning any ROMs that violate trademarks, have a poor hosting or lack legal presence. Lineage, /e/ and GOS will suffice. Same with Huawei as example of OEM without Google services.

I don't think that long elaboration is necessary, but your numbers are. Mention clearly that these changes will exclude you from service (ability to use the app) and ability to stay as their client. Request official clarification about Google services requirement to be posted by the company.

The current state is that new logins meet an error, while update may kick you out any moment, if they enforce the check for existing sessions.

https://discuss.grapheneos.org/d/17714-revolut-mobile-finance-not-supported-on-devices-with-custom-firmware-problem/

I just realized something: this camera sequence must suck for perspective jump between main and tele. I presume their choice came from thermals.

Looks like the emulated system of the new Android terminal feature runs on different TTL than host system, so net hostility measures that discriminate traffic on the basis of origin start to mess with terminal user just like with hotspot. Termux wins again ☺️

So Xiaomi wants people to pay twice the Chinese price for their European phone units. Then by using extreme measures in China, it makes sure that midrange devices are no longer worthy of import.
So you overpay just like you're expected to by buying in your local official distribution, just to be met with stuff like this. If nothing changes next year, the reliability of paid gray market bootloader unlock will vastly surpass the official method, no matter how hard you try. It's already the case. For many people, this section of Xiaomi Community app is already completely useless.
If they fully lock down their devices, at least no one will live with illusion that they're unlockable for free.

Soooo...
It works without GMS, at least the version from AppGallery. I can't say anything about any potential hardware attestation requirement, but it seems increasingly likely that we end users have a skill issue. The checker inside the app is most likely mad about the indicators snitched directly by device (bootloader, TrustZone?) itself, humbly passed by the affected Android ROMs.

The irony is usual: it'll work on a rooted device with proper hiding or worst possible tasteless ROM, but won't work on the proud official distributions of most popular projects, as they choose not to spoof the state of device, letting app vendors weaponize their own honesty against them.

For reference, the test was conducted in work profile of bl locked Motorola S50 Neo, with Google Services disabled and the SPIC result confirming that.

For some example:
https://source.android.com/docs/security/features/verifiedboot/boot-flow#locked-devices-with-custom-root-of-trust

Your device will snitch by default that your AVB is yellow rather than green, if you're using Graphene with locked bootloader just like you were guided to.