so if I upgrade from a 3XL to a new pixel 6 on graphene can these backups be used?

I use multiple profiles.
Am I able to backup all my profiles at once or do they need to be backed up seperately?

    Seedvault is not as reliable as it should be. I would additionally do a manual backup of the most important data.

    ditka use individual apps internal backup/export tools as found in Signal, Aegis, KeepassDX, Feeder etc export Contacts, Calendar etc (ie as can be done in stock and SimpleMobileTools apps) and backup internal storage to a USB Drive for all your profiles.

    11 days later
    4 months later

    Hulk Is there a timeline for this feature? I'm currently validation some solutions and would really like to use the official backup tool.

    • Hulk replied to this.

      Rnd3sB3g13rng
      Unfortunately no timeline is available at this point.

      Keep in mind that GrapheneOS project could also use more resources in order to be able to facilitate more requests like this.

      Please consider donating. If everybody pitched in, the project would be able to have more full time developers working on all kinds of new features!

      You can find out more information about donating to the project here:
      https://grapheneos.org/donate

      Thank you!

        4 months later

        Hulk Is there a specific amount of donation that would noticeably support development of a more-robust backup solution? Obviously the GrapheneOS core developers aren't bounty hunters, but since this is an announced goal of the project, is there some amount that would help a bunch toward backups?

        I would actually like the idea of community funding.
        "Obviously the GrapheneOS core developers aren't bounty hunters"
        This is one way of looking at this. Flawed idea imo.

        Think of it like a Kickstarter. Donate 1 million and we will implement XYZ.
        Why can't it be the same? With a few sane adjustments of course.
        But for example, you want feature X, there is 10k amount for it, once it reaches
        this goal, it's implemented. Yeah, it makes the project trashy and pay-for-feature,
        like many games where you have to pay to win, but well, at least it's a thing to consider.
        I know this bare idea is bad, but it's possible to make goals that once reached, development
        time will be focused towards it. Better camera, backup, etc.

        • de0u replied to this.

          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.

            de0u

            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.

              2 months later

              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.

              12 days later

              @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.