Yeah... no offense, but Android is like a toy for me. The lack of root already eliminates half the stuff I would want to do or need to do on a regular basis. The lack of any professional software is another big hit. No video editing, coding, CAD, photo editing and especially anything related to audio production makes Android (and other mobile OS'es) a big no-no. Even Apple tried to port their Pro apps to iPadOS and failed miserably.
Android (and everything iOS/iPadOS) is just very limited. You have basically no control over your system and the hardware and the cherry on top is the limited selection of professional software mentioned above. If you want to browse the web, watch some Netflix or read the news, you will be very satisfied. I for once will not ditch my desktop anytime soon.
boarim
- Joined Nov 4, 2022
Privacy and computer security enthusiast. Ideal software are FOSS, minimal and follow a KISS approach. By the way, I use Arch.
Android 15 QPR2 is moving 6th/7th/8th generation Pixels to the Linux kernel's 6.1 LTS branch already used for 9th generation Pixels. This will reduce the kernel branches we need to support down to 6.1 and 6.6. There will likely need to be a yearly migration for all the devices.
Linux kernel increased official support time for the Long Term Support (LTS) branches from 2 years to 6 years, mainly for Android devices using Generic Kernel Image (GKI) releases. However, it was recently reduced back to 2 years. Pixels will need to start migrating every year.
It will likely take around 6 months for a new branch to be considered stable enough with most regressions resolved and another 6 months to successfully integrate and ship it. Therefore, 2 years of support implies yearly migrations to keep up rather than doing it every 2 years.
Upstream LTS releases are closely connected to Android. Moving to 6 years of support was likely closely connected to the Pixel 6 moving to 5 years of support. GKI made the drivers far more standalone and easy to migrate, and Linux moving back to 2 year support is likely related.
Google has been testing newer kernels with the Pixel 6 and later for years. They have 6.6 and newer mainline kernels working fine already, it just takes a long time until the kernels are stable enough to consider shipping them. It's great that it's finally going to be happening.
Newer kernels bring many new features and increasingly complexity which means they bring lots of new security bugs. Older kernels get an increasingly small subset of bug fixes including security fixes backported in the LTS releases. Newer kernels also bring new security features.
Using a year old kernel for around a year and then upgrading to a new year old kernel is likely the best balance that's available. With 2 year support time, they can focus on backporting more patches and providing more testing/stability since there will be far fewer LTS branches.
It's not commonly understood that Android itself only has a single LTS branch, which is current Android 15. It receives monthly and quarterly updates. It moves to a new LTS with a yearly update after it has gone through many months of public testing via Developer Preview / Beta.
Many people including journalists covering it in tech news media wrongly believe Android's monthly security patch releases are the monthly releases. No, the monthly security patches are backports of a subset of the privacy/security patches to older releases. They're incomplete.
Android's monthly releases have many changes beyond privacy/security patches even when it's not a quarterly or yearly release. They also have a lot more privacy/security patches than the Android Security Bulletin backports. They backport High/Critical severity patches, not all.
These updates are a major factor in why Pixels are the only Android devices with competitive security with iPhones. Pixels also have a lot of hardware security features not implemented on other Android devices. They also have higher quality of implementation across the board.
Google will likely require other OEMs start upgrading kernel branches. However, standards for other OEMs are always far lower than the standards met by Pixels. For example, many important hardware security features are recommended in the CDD, not mandatory, or not even listed.
We aren't aware of any OEM trying to keep up with the monthly releases, only OEMs skipping all the monthly/quarterly releases but trying to ship the yearly release around the official launch. Only Samsung tries to keep up with the new security features, but lags quite behind.
Other Android OEMs do the bare minimum required by Google unless their SoC vendor (generally Qualcomm) hands the feature to them on a silver platter with no additional cost. They largely ship the monthly security backports now, but with significant delays or skipping some months.
The reduction of support time for Linux kernel LTS releases from 6 years to 2 years is likely going to become a major problem for non-Pixel Android devices. Google will likely require them to upgrade but probably at a very delayed schedule where they fall out of support first.
Our official hardware requirements are listed here:
https://grapheneos.org/faq#future-devices
You can see support for Linux 6.1 or 6.6 is already a requirement for new devices. We'll be adding a requirement to upgrade the kernel branch because it will be essential with 2 year Linux LTS support.
Social media threads:
X: https://x.com/GrapheneOS/status/1860365266921603389
Bluesky: https://bsky.app/profile/grapheneos.org/post/3lbmyp4jfi22b
Mastodon: https://grapheneos.social/@GrapheneOS/113533415116755738We've added the new official Flarum GDPR extension providing support for account anonymization and data export. These are available in your user account's settings at the bottom as Erase Account and Export Data.
Erase Account takes 30 days to happen automatically but a subset of the mods can manually approve the requests earlier. We'll wait a few days to give people time to cancel. This will delete all the account data and reassign the public data including posts to an automatically created deleted user account to replace your account. We can choose to trigger full erasure for an account where all posts are deleted but will not do that in practice. Posts are public and crawled/archived elsewhere so it wouldn't accomplish much and would ruin a bunch of discussions, so we're using the anonymization method as the default.
Everyone, nominate GrapheneOS as a beneficiary for Proton's 2024 Charity Fundraiser! It just takes a minute and you can do so here, just click on the purple "Tell us who to support" button near the upper middle of the page or click here. The Foundation being nominated will receive tens of thousands of USD. Share the link!
- Edited
Synth There is a great FOSS keyboard called fcitx5-android which is the implementation of the open-source fcitx5 im. For JP support use the Anthy plugin.
This keyboard also supports pinyin, jyutping, hangul and etc.
boarim Xtreix : You can check out https://gitlab.torproject.org/tpo/applications/vpn
- Edited
In April 2024, one of our users did their own testing for VPN leaks on GrapheneOS and discovered multiple issues with the standard Android leak blocking. We've addressed both the network DNS leak when 3rd party VPN apps go down and apps bypassing the VPN via multicast packets.
We've been working on it since April 2024 and have discovered multiple other kinds of leaks. Our latest release addresses all of the known multicast packet leaks, which includes the issue they reported and also 2 more issues we discovered ourselves:
https://discuss.grapheneos.org/d/16118-grapheneos-version-2024092900-released
We initially shipped our multicast leak blocking in our 2024091700 release but it had to be rolled back due to a severe compatibility issue with IPv6-only networks. Some carriers have IPv6-only mobile data for some or all users with 464XLAT for IPv4 so it's not an edge case.
There were several apps including KDE Connect lacking proper error handling for multicast system calls which were crashing from uncaught exceptions. These apps should be fixed but we need to be compatible with buggy apps so we still would have had to roll back our changes.
DuckDuckGo app has an "App Tracking Protection" which was going into a panic from multicast filtering and spamming enormous numbers of packets which were acting as a DDoS on routers and breaking entire local networks.
Both the IPv6 and app compatibility issues appear resolved.
The issue found by a GrapheneOS user in April 2024 was apps being able to bypass Android's leak blocking by sending multicast packets themselves. We also found other leaks via kernel-generated packets. Our eBPF filter work addresses all of these issues:
On Android, each user or work profile has their own VPN configuration. Owner user VPN is used for privileged system processes unless they apply special rules for packets.
There are checks to only permit processes sending packets via allowed networks, but we found a hole in it.
We discovered apps can partially bypass these restrictions for VPN tunnels owned by other profiles by using multicast packets. We were unable to figure out an easy way of resolving it with eBPF so we're using netfilter for this part of our leak blocking:
https://github.com/GrapheneOS/platform_system_netd/commit/036d9afd8c3c240fd4ae3a0d2a5059bcaf43fd91
In May 2024, we shipped strict DNS leak blocking to block both the reported leak to network DNS and also leaks to VPN DNS servers outside the tunnel:
https://github.com/GrapheneOS/platform_system_netd/commit/ab1a83dc36e17c4ec61def8cc7386f908e054add
The initial strict approach was reverted before it reached Stable due to VPN app compatibility issues.
We currently use a less strict implementation blocking all leaks to network DNS servers, which fixes what was reported in April 2024 but not everything:
https://github.com/GrapheneOS/platform_system_netd/commit/91caf5c858888cf2dc4bea854e5d3c7ceb2e507a
We're working on a stricter approach that's compatible with ProtonVPN, but it's very hard to test.
There are 2 remaining holes we discovered and don't cover yet:
1) Queries to VPN DNS outside the VPN tunnel
2) Android 14 inbound packet leak blocking is incompleteWe know how to block both kinds of leaks, but we need to be very careful to do it without breaking some VPN apps.
We recently hired the developer who made of our 2-factor fingerprint unlock feature that we'll be shipping shortly after Android 15 is released. They did all of this multicast leak blocking work and are working on fully resolving the remaining 2 already partially resolved issues.
GrapheneOS currently has 6 full-time developers and 1 part-time developer. There are multiple people working as volunteers or who have applied to be hired who we want to hire. Can help us do that with more donations: https://grapheneos.org/donate. We make very good use of the money.
We're very open to helping to get these issues fixed for all Android users. Google simply needs to start treating us fairly and realize collaboration is a 2 way street. We've found more severe bugs than VPN leaks. Ready to help them as soon as this stops:
https://grapheneos.social/@GrapheneOS/112916683153814021
This post is also available on social media platforms as a thread:
X: https://x.com/GrapheneOS/status/1841236289263116381
Mastodon: https://grapheneos.social/@GrapheneOS/113234906513344711
Bluesky: https://bsky.app/profile/grapheneos.org/post/3l5igzdbwjv22- Edited
Hello GrapheneOS community!
I am writing this post today because for the longest time I have wanted a good Japanese input method or keyboard that is also free software, or at least open source to use with GrapheneOS, and it seems that Japanese input is somewhat neglected since I have not found very many input methods/keyboards at all.
The only one that seemed particularly good to me (as a non-speaker) is Mozc for Android, I've used this even before I started using GrapheneOS, however, obtaining it for Android lately has been quite difficult.
- F-Droid has a prebuilt version, but it is only for armeabi-v7a, aka 32-bit, and is from April of 2019!
- Source is available at https://github.com/google/mozc, but the cllient code for the Android APK is deprecated
- I have found other sources of prebuilt APK files, but I do not necessarily trust these like I do the F-Droid build, or the Mozc source code
Luckily I stumbled upon a blog post out in the wild of someone who managed to build a working APK from the F-Droid source code tarball!
https://blog.tlfoxhuman.net/2023/04/08/how-to-build-mozc-for-android
That post is in Japanese, but using a translator, I went ahead and tried to follow those instructions while making the following changes:
- I wanted to use the real github repo for Mozc, rolling back to the last commit that would allow me to build an APK file, rather than using the F-Droid source tarball
- I used the version of OpenJDK 8 from the ubuntu jammy repositories, the author's instructions involve installing a .deb from Azul
- The author downloaded an external version of guava and protobuf from maven for their build environment, I tried using the versions of guava and protobuf included/built from the Mozc repo, but had to use the version of protobuf they linked to in order for the build to succeed
I did make the APK build, made it build for arm64 (so I now have a 64-bit version yay!), signed it using my own keystore, and installed it onto my device.
However, you can no longer build the Mozc for Android APK using the most recent source, it was deprecated, probably to remove it as an alternative for their proprietary Google Japanese Input, aka Gboard. To build an APK, you need the source code from Feb of 2018 (!!), and upon opening Mozc for the first time I get a warning that it was made for an older version of Android, targetSdk/minSdk show as 23/14 respectively.
It's pretty clear that Mozc is not really meant to be used on modern versions of Android, in fact, the instructions from the blog post I linked above uses the following:
- OpenJDK 8 (from Azul)
- Guava 18.0 (2 vulnerabilities according to the author)
- Protobuf 3.5.0 (4 vulnerabilities according to the author)
- Python 2 (used in the build process)
So there could be security concerns involved in using this as well, nonetheless, it is one of the few open source Japanese input methods/keyboards available for Android, and in my opinion, pretty much the best despite its age, and functions perfectly well without network access, which is why I went ahead and made the effort to build, sign, and install it myself.
It also has a Godan keyboard layout that is only available via Mozc and Gboard AFAIK, it took some getting used to, but I grew to like it, it is a 15-key layout, in a 5 column by 3 row grid, the vowels on the leftmost column, and some consonants on the other two columns, the rest of the consonants available by flick gestures.
I don't know much about security on Android, so I'd like to know what the risks are in using this, how those risks can be mitigated, etc. I would also be glad to share the instructions for building it if desired, or discuss any other aspect relating to Mozc/Japanese input in general.
AlphaElwedritsch Developer of Accrescent here. Yes, there are only a handful of apps available right now. The reason for this is that the recent focus hasn't been directed on getting more apps in the store, but instead on internal changes to allow Accrescent to include more features and scale to more users. It will be able to include more apps once more of those changes are implemented.
- Edited
We're planning on phasing out support for 32-bit apps on 5th/6th generation Pixels where they're still supported. They were already phased out by Android for 7th generation Pixels and later, and by ARM for 2nd generation ARMv9 Cortex cores onwards. Since 7th/8th generation Pixel users are doing fine without them, we want to bring the improved security to users on 6th generation Pixels which still have a lot of support ahead of them. It will also save a significant amount of build time and bandwidth, particularly when we can move to 64-bit-only builds of Vanadium.
The main benefit is dropping all the 32-bit ABI support from the kernel including a bunch of awful legacy cruft for emulating legacy ARM features no longer supported by hardware.
The next release will add a clear warning to each launch of 32-bit-only apps. In nearly all cases, people just need to switch to proper builds of apps which aren't 32-bit-only such as the ones distributed by certain 3rd party mirror sites where users accidentally ended up on 32-bit-only builds.
It hasn't been possible to install 32-bit-only apps from the Play Store on 64-bit-capable devices since August 2021 and they blocked uploading either new apps or app updates without 64-bit support since August 2019.
Posting AI generated content in our community is only permitted for people who are using an automated translation tool to work around not being fluent in English. Use of a translation tool must be marked in either your user bio or the first post in a thread where you're using it. Use a dedicated translation tool, not a generic text generator like ChatGPT.
AI generated text is still usually very easy for us to spot. Both spammers and malicious trolls are making more and more use of these tools to attack the project. We cannot distinguish people who do not believe they're causing any harm by using these tools from people using them maliciously. Posting walls of verbose text written in the tone of an expert by an AI with no actual understanding involved is harmful to our community. It wastes the time of moderators, developers and community members along with misleading people. People shouldn't have to waste their time responding to machine generated nonsense which comes across as a very serious but very misguided post.
Suspensions for violating this rule will be permanent if the content wasn't marked as AI generated. These AI text generation tools are essentially optimized for generating plausible sounding misinformation and their use will be treated as malicious deception. Multiple accounts have been suspended for clearly using these tools without saying so. Please stop doing this. People invest a lot of time helping others in this community and do not want to waste their time responding to machine generated nonsense.
I don't know whether this is for everybody - everyone has probably their own individual reasons and necessities for deciding against Google and/or in favor of separation through profiles.
However, there are probably some here who maybe have a security and privacy setup much more than their actual threat model requires and for whom it might do good to shift down a gear (privacy fatigue is also a threat) - so thank you for sharing your experience - less is perhaps sometimes more.
And as fid02 stated: Sandeboxed Google Play rocks 🤘
Twitter / X: https://twitter.com/GrapheneOS/status/1765044792965099595
Mastodon: https://grapheneos.social/@GrapheneOS/112043931292618398
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kmxkhmymvg26
This month's Android release is the first one based on the new development model heavily centered around quarterly releases. It's essentially an early variant of Android 15 with many of the features disabled via feature flags. We're essentially doing a major yearly release port.
We were aware this was going to be the case, but it's still going to take a bit longer than usual. This port should be the hardest one since it's the first one. Future quarterly and yearly releases should be much smaller than this one. It should make the yearly ports much easier.
There's going to be a temporary disruption for us from moving to the first quarterly release under the new model. We didn't treat it as a yearly release with lots of preparation but we'll try to get it as done as quickly as the Android 14 release where we prepared for months.
Despite causing a lot of pain for us for this first migration, the new release model should be a substantial benefit to us. It will mean the changes are spread out throughout the year in quarterly releases and many will get shipped disabled via feature flags so we can port early.
In the very short term, this is a massive pain and disruption for us where we need to put in similar work this month as we did for the yearly Android 14 and Android 13 ports. Going forward, things should be easier. It may also help mitigate the issues caused by mainline modules.
Nearly all our changes are ported and we have builds running in the emulator. There's a lot of work remaining to fix regressions and get device support working. If we aren't done by the end of the day, we can do a security backport release. We'd prefer avoiding an extra release.
We're likely going to need to move the end-of-life Pixel 4a (5G) and Pixel 5 from extended support to legacy extended support. This is a major release with a similar level of changes as Android 13 QPR3 to Android 14, and we don't want to waste our resources on insecure devices.
We hold onto the Bitcoin, Monero and Ethereum. We pay nearly all the project members with cryptocurrency directly. We have to convert Cardano, Litecoin, etc. to Bitcoin or Ethereum occasionally because we don't get nearly enough to use them for transactions. It's getting harder for project members to convert Monero to fiat but some project members only feel safe being paid privately via Monero due to attacks on the project and extreme harassment targeting project members. Donating Monero helps us pay these developers, as long as they can still find ways to convert it to local fiat.
Thanks for the update!
missing-root You have an explanation about why Flarum for this forum here.
[deleted]
Termux, and ffmpeg. Handbrake is based on ffmpeg so if you figure out the commands (not too complex) you're there.