Beerman there are minor bugs / glitches, but I've been using it for months without much issue. Unfortunately, it's the best option I could find (for my needs) other than the stock launcher that supports private space.
BBeerman
- 11 days ago
- Joined Nov 10, 2022
I'm using it since it supports A15 and works w/o any problems.
Lawnchair 15 has been running quite well here for three months now.
Beerman
left mine over night, the battery was at 93% when i disconnected so mine seem to behave in the same way.- Edited
In April 2024, Pixels shipped a partial implementation of our January 2024 proposal for firmware-based reset attack protection. Fastboot mode now zeroes RAM before enabling USB. This successfully wiped out the After First Unlock state exploit capabilities of two commercial exploit tools.
Several other improvements were made based on our January 2024 vulnerability reports and proposals including an implementation of wiping data before rebooting when a wipe is triggered. We shipped an improved version of this for our duress PIN/password feature before the feature shipped for Android.
We made massive improvements in GrapheneOS to defend against these attacks since January 2024.
For ARMv9 devices, we greatly improved our hardware memory tagging implementation in hardened_malloc, deployed it for the Linux kernel allocators and greatly expanded the use of PAC and BTI across the OS.
We replaced our decade old feature for blocking new USB peripherals while locked with a greatly expanded and far more secure feature. The new approach blocks USB-C connections and USB-C data at a hardware level with expanded software-based blocking as a fallback (https://grapheneos.org/features#usb-c-port-and-pogo-pins-control).
We started deploying RANDSTRUCT for the kernel, which will eventually be used to have multiple possible struct memory layouts for each device model chosen randomly at boot. Our work on reducing kernel attack surface also continued. We plan to focus more on Linux kernel security going forward.
Our locked device auto-reboot feature from 2021 was replaced with a more secure approach preventing bypasses via crashes (https://grapheneos.org/features#auto-reboot). It also avoids chain reboots without introducing a security weakness which makes low timer values such as the minimum 10 minutes far more usable.
We shipped our 2-factor fingerprint unlock feature planned since 2015 (https://grapheneos.org/features#two-factor-fingerprint-unlock). It allows people to avoid reliance on secure element security with a strong passphrase while keeping convenience. Fingerprint + scrambled PIN also defends well against being recorded unlocking.
We recently added an implementation of zeroing RAM at boot in the kernel to match what fastboot mode does to cover anything not previously zeroed on free. Several more major improvements specifically against the physical data extraction attack vector are planned. For example, we plan to add a toggle for essentially toggling off Device Encrypted data.
Beerman You can use an app providing a keep awake tile and we could provide a tile for it bundled with the OS.
n2gwtl Having native debugging disabled without enabling hardware memory tagging was triggering the alert due to Chromium 132 adding code to log debug information when memory tagging is enabled for Chromium as Vanadium does but not enabled by the OS. It has been resolved in the latest Vanadium release.
Vanadium version 132.0.6834.79.2 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/132.0.6834.79.2
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
- Edited
NetRunner88 It is strange that apps do not compile anymore, compilation is part of the security process right ?
For me the part of the update where apps are being compiled was expected and now for me it is perceived like an anomalyMany including me noticed the absence of app optimization after reboot yesterday, and brought it up in the alpha/beta channel. Apparently the optimization is automatically skipped whenever possible, when there are no relevant changes to the system that would require a recompile. This release didn't need any recompile. This is what the official GrapheneOS account wrote:
<grapheneos:discord> it's quite possible this update just didn't need recompilation
<grapheneos:discord> the packages show as speed compiled in dumpsys package...
<grapheneos:discord> this appears to be why (re @grapheneos: it's quite possible this update just didn't need recompilation)
<grapheneos:discord> this update simply had very few changes to Java libraries...
<grapheneos:discord> it's confirmed that there were no changes to boot class paths in the update so no need to recompile apps
- Edited
Hello.
Here it is the petition link.
https://www.change.org/p/stop-google-from-limiting-custom-roms- Edited
Do not uninstall GSF. The original suggestion to do so has been retracted. It's not recommended or needed, and even on this latest release, doing so might break some things. Please leave your sandboxed Google Play installations as they are.
New installations of sandboxed Google Play on Android 15 won't include GSF, but for those that do, please leave them be.
Optional. You can deactivate it instead and see if that causes any problems first.
- Edited
Despite many attempts over multiple weeks to explain how this works and that OP's idea about how it works is flawed, it doesn't seem like any explanation we can offer will be enough. A temporary suspension has been issued which will become permanent if this doesn't change in the future.
It is fine to not understand everything, but please try to respect the team's time when they provide an explanation. This specific topic has had hours wasted on it at this point, and we keep circling back to imaginary threats stemming from a misunderstanding of how the feature works.
- Edited
GeorgeSoros It would go against GoS user base purpose.
As defined by you personally? I think the opinions of some other people, especially the folks with little lightning bolts on their avatars, might be relevant also.
a) Will GoS have this feature?
The feature you think exists does not exist, so no, and not even the stock Pixel OS has that.
b) Does GoS airplane mode definitely prevent the satellite function (however you define it) as well as e911 tracking from being activated in an "emergency"?
On the stock Pixel OS, that's not relevant since it isn't used without specifically activating it. By making an emergency call, you're explicitly asking to disable airplane mode. If you don't want to make an emergency call, don't make an emergency call.
We've already been clear that GrapheneOS doesn't currently support this and that we would need to go out of the way to implement support for installing it and enabling it if we wanted to do that. It's not currently something we plan to do but it wouldn't negatively impact you for us to implement support for people who want to use it doing that. Not clear what issue you have with people being able to choose to use a feature.
In Android 13, otapreopt was used to do precompilation of apps in the background in the Finalizing update step before reboot. However this is broken in Android 14, and is therefore, at least temporarily, not possible on GrapheneOS.
otapreopt being broken in Android 14 led to very long boot times after each update, of more than 30 minutes, as GrapheneLover has said, which is considered impractical.
Therefore, since release 2023102300 speed-profile compilation for user installed packages has been used to significantly improve boot time during first boot of an update. Apps are now recompiled with full speed optimization in the background with a progress notification and a notification when it's finished for respawning apps.
Hope that helps to clarify things. I have based this response on the release notes on the GrapheneOS website:
https://grapheneos.org/releases#2023102300This is fixed for the next release.
Beerman here's the issue: https://github.com/GrapheneOS/os-issue-tracker/issues/2514
Known issue, is being looked into and will be addressed.
