uid0gid0 I think when it comes to which model the GrapheneOS developers work according to, they are the ones who decide. For example: We're not contract workers, we're not accepting bounties, we're not doing something just because you keep on pinging us about it.
Hopefully backups is different because it's a public goal. So I'm curious as to whether some specific volume of donations might be supportive of this existing goal.
I agree. They don't want to set a bad precedent though.
IMO, they are leaving money on the table. GrapheneOS is certainly already worth a one time donation. But it's hard to justify recurring donations when they routinely make people feel like crap just for asking. It feels, and this is subjective, that non devs are looked down upon, because they aren't willing to learn how to code. As if they even would consider accepting code from novices anyway. So the masses must just accept the priorities or lack thereof, for any feature popular or not. It's fine, but not really inspiring of donations.
I feel that manual backups are tricky and time-consuming - as far as I know you have to go to each app one-by-one and it depends on what the app offers. There are also various system settings. So I'd like to explore alternatives.
What does anyone think about using adb for backups? It seems like it could be completely automated in a script.
@WhiteKnight adb backup / restore is deprecated for anything other than debugging. It doesn't back up data for non-debug builds of apps targeting Android 12 and above. You're trying to use a development tool and are drawing wrong conclusions about the backup system based on it.
allowBackup="false" only disables cloud backups for apps targeting Android 12 and above and the traditional backup file exclusion system also only applies to cloud backups. Targeting Android 12 and above is mandatory for apps in the Play Store. The new file exclusion system differentiates between cloud, end-to-end encrypted cloud and device-to-device backups. There's no option for apps to disable backups, but they could exclude all their files from them. The vast majority of apps do not exclude their files from device-to-device backups, which is what gets used by the backup system.
Considered alone, yeah it's sucks that users who put their digital life and trust in GOS feel disempowered like this.
On the other hand - how much of a voice do users have in the Google or Apple ecosystems?
Can we find examples among other OSes who use a different funding / resource allocation / prioritization structure? (LineageOS, etc?)
The Kickstarter model is not a good one for security and privacy minded OS in my opinion, many problems with the kickstarter funding model. I think there are good reasons why most creators on the KS platform move on to forming their own org independently of KS after their initial success, rather than stick around on KS long-term.
GrapheneOS
Great many thanks for explaining about adb.
When I run a SeedVault backup about 40% of my apps are reported as "apps that do not allow data backup". Seedvault has open issues Initial support for backup of D2D-only apps and Pretend to be a device to device transfer - fake-d2d. These observations suggest that the backup system is not currently using device-to-device backups. Or have I misunderstood again?
Would be handy if there was a OS based backup system that creates a local backup file of like the settings, sms and call history, contact list, etc., which then can be either be stored on a computer or a cloud storage like Proton Drive, so I don't need to look for apps on the Play store that can do these things.
WickedMouse
You can use the seedvault service via Settinngs > system > backup to do that.
Worth considering though
https://hub.libranet.de/wiki/graphene-os/wiki/Backups
GrapheneOS is fantastic and automated, reliable backup is the only critical part that I miss. I hope you'll build a great solution, you have my support guys.
WickedMouse Would be handy if there was a OS based backup system that creates a local backup file of like the settings, sms and call history, contact list, etc.
I have used "SMS Import / Export", which covers SMS/MMS and contacts. The need to manually use airplane mode is a little clunky, but it's been useful.
A general backup solution would indeed be great, but we will need to wait.
de0u Yeah I've been using "SMS Backup & Restore", to save them all locally and then copy them to PC, so use the same app on the new/other phone to import them.
As there is no good backup solution in sight, my strategy is to store data on /sdcard where possible and from there I back it up with another app. Obviously this does not work for all apps, but I have started to prefer apps that can store on /sdcard and will be changing code for apps that I compile myself.
Where is Google's backup mechanism implemented; in the core OS or in GSF? If it is in GSF, one could create a shim like many other shims in GOS. It would be enough to support one backend, namely Rclone (link). Rclone itself supports many storage solutions, ranging from self-hosted SFTP to public cloud providers. So every user could chose his preferred backup storage.
I have tested backup. Perfect no it isn't. But pretty
damn good actually. I'm not seeing why people dislike it. At the end of tbr day I'm just so thankful for a non apple/google solution.
Thank you to the devs and community.
Yeah I've been trying seedvault the past few days it'll install all your apps , most settings are saved , contacts and call logs are saved .
But no app data , texts or pictures .
It doesn't save the important stuff
It will install backup on pixel 6 but not on pixel 6 pro half the time.
Problem is that Seedvault depends on the same functionality as "adb backup" which Google has deprecated and said they will remove it in the future. That's why a new solution is needed. As far as Seedvault is concerned, I have tested restoring individual apps from APK while a USB drive with a Seedvault backup was plugged in, and the data was restored correctly. Whether that is enough to restore an entire phone is a different question. There are a number of apps that successfully opt-out of being backed up.
A future solution should try to make use of mechanisms proposed by Google instead of working against them. That's why using BackupAgent seems to be a good idea. A future solution should also support more than one storage backend, that's why integrating rclone seems to be a promising option; one integration point, multiple backends.
