The stable version for the Galaxy S9: Android 8 (Oreo).
it was merged in Pie at the earliest: Seedvault backup as Backup/Restore transport (!48) · Merge requests · e / os / android_vendor_lineage · GitLab
2 Likes
Will it be possible to upgrade Android Oreo on an S9 to a newer version if it is stable without loosing any data? AFAIK the newer version is Q, so there is one version missing in between. Does that affect the upgrade?
please search the forum for the S9 starlte upgrade topics.
If you can wait another few weeks, early december: the weekly dev updates mention a planned OTA update for starlte Oreo stable users.
for persons not into cli and adb, you can run Seedvault via creating shortcuts to the available Activities (settings + restore) with Activity Launcher | F-Droid - Free and Open Source Android App Repository
I think you can do all the default transport register through using the settings dialog once.
(the caveat that Seedvault needs Android 12 level backup api or a backport to be fully useful still applies)
2 Likes
I just tried to activate seedvault on my FP2 /e/ os R 0.21, but I couldn’t activate it: bmgr: not found. Does this means, seedvault is not included in the actual 0.21 version?
It is enabled in R ROMs, at least for some devices. Not sure whether it is supposed to be there for FP2.
in e-0.18-r time (august 2021)
only unofficial test builds had seedvault graphique interface enabled,
not official dev or stable builds.
now it is e-0.21-r time, things may have changed
Actually that doesn’t seem to be the case. I have been working today with official dev R builds, for z3, z3c, and suzuran (all Sony devices). They do have SeedVault enabled, so long as you do a clean install, and don’t try to restore a Q data backup
To me this looks like you maybe didn’t type the command correctly (adb bmgr enabled by any chance?).
adb shell bmgr enabled in a terminal on a PC with working adb connection to the phone should always print either “true” or “false”
Hmm. So I start my FP2 in the recovery mode (TWRP), then I test:
adb devices - which is successful, I get the phone id. So adb works.
Then adb shell bmgr enabled gives me the output /sbin/sh: bmgr: not found
I tried adb bmgr enabled, which brings up adb: usage: unknown command bmgr
Any more ideas?
Thank you!
The subset of ADB commands TWRP chooses to support works. This is not the fully featured ADB you get when Android is running.
Apart from adb sideload, which requires the recovery to be put into ADB sideload mode, only adb backup and adb restore are documented as far as I see here at “HOST SIDE” … https://twrp.me/faq/openrecoveryscript.html
Apparently adb devices works, too, but notice what it displays apart from the device id. From what I’ve seen …
With Android running it displays “unauthorized” until authorized by the user on the phone, from then on it displays “device”.
With the recovery running it may display “recovery”, if the recovery supports it.
With the recovery running in ADB sideload mode, it should display “sideload”.
And I think if you query features this way, it would give you the features of the recovery, not the features of the installed OS anyway.
So, my guess is that if TWRP would even let you adb shell something like this, you would only find out that TWRP doesn’t have Seedvault.
1 Like
There you have it. 
The commands in the first post need to be executed while the normal OS is booted.
2 Likes
Vielen Dank! You made my day! Now it works!
Well, perhaps I couldn’t make it work as it intented.
For the command adb shell am start-activity com.stevesoltys.seedvault/.settings.SettingsActivity
I got this output:
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.stevesoltys.seedvault/.settings.SettingsActivity }
Exception occurred while executing 'start-activity':
java.lang.SecurityException: Permission Denial: starting Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.stevesoltys.seedvault/.settings.SettingsActivity } from null (pid=20951, uid=2000) requires com.stevesoltys.seedvault.OPEN_SETTINGS
at com.android.server.wm.ActivityStackSupervisor.checkStartAnyActivityPermission(ActivityStackSupervisor.java:1043)
at com.android.server.wm.ActivityStarter.executeRequest(ActivityStarter.java:999)
at com.android.server.wm.ActivityStarter.execute(ActivityStarter.java:669)
at com.android.server.wm.ActivityTaskManagerService.startActivityAsUser(ActivityTaskManagerService.java:1105)
at com.android.server.wm.ActivityTaskManagerService.startActivityAsUser(ActivityTaskManagerService.java:1077)
at com.android.server.am.ActivityManagerService.startActivityAsUserWithFeature(ActivityManagerService.java:3670)
at com.android.server.am.ActivityManagerShellCommand.runStartActivity(ActivityManagerShellCommand.java:543)
at com.android.server.am.ActivityManagerShellCommand.onCommand(ActivityManagerShellCommand.java:185)
at android.os.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:98)
at android.os.ShellCommand.exec(ShellCommand.java:44)
at com.android.server.am.ActivityManagerService.onShellCommand(ActivityManagerService.java:10514)
at android.os.Binder.shellCommand(Binder.java:929)
at android.os.Binder.onTransact(Binder.java:813)
at android.app.IActivityManager$Stub.onTransact(IActivityManager.java:5053)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2875)
at android.os.Binder.execTransactInternal(Binder.java:1159)
at android.os.Binder.execTransact(Binder.java:1123)
Am I guessing right that it doesn’t work? Perhaps @petefoth is right that upgrading from Q to R requires a data wipe (which I didn’t do) in order to make seedvauld work?
If you run R, the seedvault settings are accessible via Settings → System → Backup, at least in the dev build I updated to.
(the instructions in the thread head no longer apply for android11 / R seedvault >2.3 builds, see https://github.com/seedvault-app/seedvault/commit/b2cd3c76a3445066846f42fddfa366934b5ef050 - only if it is an App-debug build no permission to open the settings are needed)
I was recently looking at this on three different devices, all running the latest released v0.21-r dev build, and I found that SeedVault was accessible as you describe immediately after a fresh, clean install (i.e. wiping data befoe flashing the ROM). But if you ‘dirty flashed’ the ROM (i.e. install without wiping data), or if you restore a backup from a Q device, then SeedVault was no longer accessible. I didn’t try restoring a backup from an earlier R build because I ran out of time and motivation. My conclusion is that the availability / accessibility of SeedVault in the R UI is a bit random 
I would be interested to know what the availability is supposed to be, but I haven’t yet managed to find any requirements documentation for /e/OS
1 Like
As far as I know the restore dialog is supposed (by the seedvault developers) to be incorporated into the first-time setup wizard.