We're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.
motorolanews.com/motorola-thr...
It's annoying how good discord is. Matrix is a nice idea, but janky in practice.
GrapheneOS is the only Android-based OS providing the full security preview patches. Samsung ships a small subset of their flagship devices. Pixel stock OS gets a portion of it early but we aren't sure exactly how much since they don't follow their guidelines for listing patches.
If you've wondered how Android developer verification affects Accrescent, today we have a new blog post explaining briefly what it is, how it impacts us, and how we're responding.
blog.accrescent.app/posts/androi...
It's time for an update! Check out our blog for a new update on:
- What we've accomplished in the last 3 months
- What's next for Accrescent
Thank you to our supporters for making this possible!
blog.accrescent.app/posts/road-b...
Accrescent 0.28.0 is out, including:
- Download cancellation support
- Better update scheduling (especially on Android 14+)
- UI improvements and bug fixes
Full release notes below!
github.com/accrescent/a...
Accrescent 0.27.0 is here! This is the most significant release we've made to date:
- New, stable app store API
- Complete installer rewrite, resolving all known bugs
- Tons of new features
- More snappy, correct, & informative UI
Check it out! 👇
github.com/accrescent/a...
...I suspected it had to do with URLs not being valid paths. That worked locally, but failed in our testing environment which has longer APK URLs. The final fix was to hash the APK URL to ensure the APK name is a constant length and thus always a valid file name.
For those curious, I actually came across this because Accrescent was using APK URLs as its APK names to uniquely identify them. Those URLs obviously aren't valid file names, so an exception is thrown (for no clear reason). I "fixed" it locally by hex-encoding the URLs since...
Another day of Accrescent, another AOSP bug report: issuetracker.google.com/issues/44717...
You might say, "Why are you making file names more than 255 characters long? Do you really need to do that?"
No, no I don't. But someone had to try.
Development on our roadmap is progressing smoothly. Our next app and server releases are undergoing final testing before deployment.
We hope to make an announcement soon about what Android's recently announced developer verification requirements mean for Accrescent. Stay tuned!
Honestly I'm going the cloud-managed route right now and will probably use what's available there when I set up a standby instance. Costs more than DIY-ing it, but saves me enough hours that it feels like it's worth it to me in the end (and the easy IaC integration is a nice plus)
As in a high-availability configuration, replication, or something else? Right now I'm just using single-instance PostgreSQL and may add a standby instance in the future. Haven't figured out if I want/need additional read replicas yet to lower latency in other regions.
My experience has been similar with K8s. For all the complexity that's talked about (and I don't deny the setup hurdles), it's been quite comfortable for me to manage so far.
Since we published our blog post on the future of Accrescent, donations have increased dramatically.
According to the rates in that post, we should now be able to fund full-time development through at least May 2026!
Thank you to our community for your monumental support!
Today is the day! Read all about our development progress, view our roadmap for the future, and check out the new projects we're releasing as open source in our new blog post!
blog.accrescent.app/posts/progre...
Keep an eye out for tomorrow's blog post! We'll be posting a development progress update for the past months and a roadmap for the next few.
Thank you!
Thank you for your support!
This has been a long time in the making (including the follow-up to be posted next week). I'd appreciate you giving it a read.
I'm part of the team that discovered the #TapTrap vulnerability. We confirmed that @grapheneos.org has properly fixed it, as detailed on our site taptrap.click
Despite a small factual error, it's good to see #GrapheneOS getting some media attention.
I don't think a lot of people will miss Amazon's Appstore (myself included), but it's nonetheless unfortunate to see one of the very few Google Play alternatives disappearing. There aren't many others left.
More information on the Amazon Appstore discontinuation on Android:
www.amazon.com/appstoreonan...
With the Amazon Appstore shutting down, it's becoming even more important to invest in sustainable alternative stores you can trust.
See how you can invest in Accrescent's future! A little help goes a long way:
accrescent.app/faq#contribu...
Timestamps or other variable metadata could be annoying to deal with, but really the build system should remove those to facilitate reproducible builds.
Can't verify behavior is the same since behavior can depend on the signing block's content, but I think that's as good as it can get and is possibly not even relevant if the subject is reproducible builds.
I'd suggest using apksig(ner) (android.googlesource.com/platform/too...) as a reference for stripping out the APK signing block (source.android.com/docs/securit...) and then just hashing the remaining APK bytes and comparing that.
This. If the purpose is verifying reproducible builds, I'd be extremely careful about trusting the archive metadata and assuming Python archive parsing behavior is consistent with Android's (i.e. I wouldn't). That assumption has bitten too many people before.
GrapheneOS has a list on their attestation compatibility page here: grapheneos.org/articles/att...
I don't know exactly which apps you're using, but I happen to know Word and PowerPoint work fine on GrapheneOS.
