Nice! What kind of issues are you seeing with rotation? On my phone, the camera rotation follows the device rotation.
chenxiaolong
- Joined Nov 24, 2022
missing-root Interesting. I'm also using OBS (not flatpak though), but with the V4L2 source. Might be worth giving that a shot.
It works wonderfully--I use it nearly every day during meetings.
The only thing to be aware of is that switching to UVC (webcam) mode restarts the USB controller and it takes a few seconds to do so. Make sure you don't turn the screen off during that time or else GrapheneOS's USB port restriction feature will kick in.
Ducter I don't know if you'll run into the same issue I did. It initially behaved that way for me too (also T-Mobile USA), but Google would silently block access a day later. After the silent "ban", RCS would show as connected, but actually sending and receiving messages would fail. It wasn't until I granted the
READ_DEVICE_IDENTIFIERS
permission (https://discuss.grapheneos.org/d/1353-using-rcs-with-google-messages-on-grapheneos/352) that it stayed working (a little over 2 weeks for me now).83639273 Thanks! This also worked for me (Pixel 8 Pro on T-Mobile USA). Worked straight away after a reboot.
I granted
READ_DEVICE_IDENTIFIERS
the old fashioned way via adb:adb shell appops set com.google.android.gms READ_DEVICE_IDENTIFIERS allow
The state of the permission can be found with:
adb shell appops get com.google.android.gms | grep READ_DEVICE_IDENTIFIER
Previously, I had:
READ_DEVICE_IDENTIFIERS: deny; rejectTime=+2m21s554ms ago
After enabling the permission, I have:
READ_DEVICE_IDENTIFIERS: allow; time=+47s616ms ago; rejectTime=+7m4s585ms ago
The feature is indeed closed source and is implemented by
/system_ext/app/RepairMode
in the stock OS. It's a really simple app and I don't think it'd be too difficult to reimplement if someone wanted to. It creates a DSU (dynamic system update) slot with a newuserdata
image. This allows repair mode to use all of the stock OS partitions, except for the user data. When booting into the new DSU slot (which they namedrepairmode.lock
), the sameRepairMode
app will adjust some system settings, like disabling the initial setup wizard, the factory reset option, and the OEM unlocking option. When the user exits repair mode, the DSU slot is deleted.This is theoretically possible, but maybe not with the GrapheneOS + stock OS combination. These are the main issues I see:
- GrapheneOS does not trust any signing keys for DSUs. This can be worked around by leaving the bootloader unlocked or by building GrapheneOS from source and adding the stock OS' keys to the
/avb
directory in the ramdisk. - DSUs can substitute any partition, but only the ones mounted by Android are actually used, such as
system
,product
, andvendor
. Partitions that are loaded by the bootloader are always the GrapheneOS versions. Notably, this includes the boot images (kernel + ramdisk). I don't know if GrapheneOS' kernel is compatible with the stock OS. (If it is, it's necessary to exclude the stock OS'system_dlkm
andvendor_dlkm
partitions when installing the DSU so that you don't mix the GrapheneOS kernel with the stock OS kernel modules.) - Assuming everything works, it's necessary to disable the OTA updater in the stock OS. DSUs aren't really isolated and have full access to the device. The stock OS is not designed to be installed as a DSU and doesn't take any precautions to make sure it doesn't break things. This is problematic because the OTA updater can potentially overwrite, for example, GrapheneOS' boot image partitions. If that happens and the
OEM unlocking
checkbox is disabled, then the device will be effectively hard bricked. (No way to unlock the bootloader to fix the damage it caused.)
At some point, I'll probably try this just for the fun of it. It'd probably not be practical for regular use though (and definitely won't work with official GrapheneOS builds).
Google Pay
This will not work, unfortunately. When booting a DSU, the GrapheneOS
vbmeta
and boot image partitions are still used. Thus, hardware attestation will still report the GrapheneOS public key, not Google's. (Well, technically, it'd report your own key because you'd need to build GrapheneOS from source with modifications to be able to install any DSU.)Are you using a Linux system for your sideloading? I only ask because I have both Windows and Linux available to me and was wondering which is easier to do this with?
Either should work equally well, though Linux may be easier because no extra drivers need to be installed.
- Edited
I ran into this with my Pixel 7 Pro before. While it was more likely to happen during an update, it was something I could trigger eventually just by rebooting continuously. (And much more frequently if I alternated between booting into Android, recovery, and rescue modes.) I was not able to reproduce the issue with the stock OS.
Since it's almost certainly a bootloader bug, I started comparing GrapheneOS' AVB setup with the stock OS' AVB setup. The one notable difference is that GrapheneOS puts the boot-related hash descriptors directly in
vbmeta
, while the stock OS signs those partitions directly and puts chain descriptors invbmeta
. What GrapheneOS does is perfectly valid, but it ends up using fewer rollback index locations (1 in GrapheneOS, 5 in stock). Maybe the bootloader has some obscure bug that doesn't deal with this scenario properly.I ended up rebuilding and resigning GrapheneOS' partitions to more closely match the stock OS, but unfortunately, I couldn't finish testing before the deadline for sending in my device for a trade-in.
For folks running into this after an update, the automatic rollback after a few reboots should resolve it. If you're unlucky enough for it to happen just from a regular reboot, try booting into recovery and sideloading the latest update. If recovery mode also doesn't boot, try rebooting into rescue mode and sideloading with
adb rescue install <grapheneos zip>
.When an app uses the system file picker to create a new file or open an existing file, that goes through Android's Storage Access Framework. The system gives the app permission to access the selected file only and nothing else. This method of selecting files does not require any permissions because the app can only access what the user explicitly granted. This is true for Android in general, not just for GrapheneOS.
The
External Storage 1 item
is referring to the.kdbx
file you selected. With adb, you can see that the system only granted access to the specific file by running:# For keepassdroid: adb shell pm dump com.android.keepass | grep UriPermission
You should see something like:
UriPermission{93a7c7a content://com.android.externalstorage.documents/document/primary%3Apath%2Fto%2Fyour%2Ffile.kdbx [user 0]}