Closed bdantas closed 5 months ago
I can confirm that the file /data/user/0/com.machiav3lli.backup/files/assets/tar.sh
does exist.
I tried uninstalling NB, reinstalling, and using a brand-new backup directory but the problem persists.
If I go into Preferences -> Advanced -> Developer settings
and disable both backupTarCmd
and restoreTarCmd
then no error during data backup. Does this suggest what the root issue might be?
All is not well, however. NB hangs when a backup is being restored. Trying to launch the partly-restored app causes it to crash.
Oh, well. I'll be sticking with OABX 7.0.0 for now. It seems recent changes in the app broke its compatibility with my OS.
tar.sh is used by tarcmd (which is short for "using tar command"), so it's not a root cause. I don't see, why this could go wrong.
tar.sh is a script that is copied from inside the apk to NBs own data area, to be able to call it via su.
As you said, it is indeed existing. So this means, NB has access.
We need a logcat from starting NB and a logcat from a backup.
Please also provide a ''' toybox ls -AlZ tar.sh ''' invoked inside it's directory (or add tthe path to tar.sh)
it's also suspicious that the error message is talking about an id
apk works, because it's not using tar.sh
which root solution do you use? If it's not Magisk, it will probably not work.
Magisk manages mount namespaces and we need --mount-master on thevsu command.
SuperUser could be ok, too, at least it invented that option, but it's kind of untested (there are no positive reports).
I think usual built in root methods do not work. This still doesn't explain the error message, because tar.sh is part of NBs own data, so access shoukdn't be a problem. Though error messages can also have errors, unexpected internal exceptions often get wrong labels. The message isn't from NB, it's just a copy from what the system or su command or some API says.
you directly updated from 7.0.0 to 8.1.3? so you don't know how intermediate versions worked?
to create those logcats you should use a neo variant to get the real names in the log instead of those mangled short names (a: t7.d.b
, t7.d$b
etc.)
I tried upgrading from 7.0.0 to 8.1.3. I also tried uninstalling and doing a fresh install of 8.1.3. I did not try intermediate versions.
My root solution is the simple addonsu-16.0-arm64-signed.zip
provided by LineageOS. LineageOS 16 was the last version to have the addon. I do not use Magisk.
Here is the terminal output you requested:
# cd /data/user/0/com.machiav3lli.backup/files/assets
# toybox ls -AlZ tar.sh
-rw------- 1 u0_a151 u0_a151 u:object_r:app_data_file:s0:c151,c256,c512,c768 671 2022-10-07 09:25 tar.sh
I wish I had time to uninstall addonsu and try Magisk. When/if I upgrade my phone to one for which addonsu.zip
is not an option, I will try NB with Magisk.
Problem resolved when I uninstalled addonsu and setup Magisk, so I can confirm that the issue had something to do with root method.
I ran into this issue when using LDPlayer with the Root option enabled. My guess is that LDPlayer also uses something apart from Magisk, i.e. SuperSu or similar.
I'm using LDPlayer because I can have both it and my current ROM running at the same time, so I can test porting things over without having to reflash and restore backups from google play. I have yet to see if there are any issues with different android versions, just trying things out at this point. I'll update in the future with results.
I ran into this issue when using LDPlayer with the Root option enabled. My guess is that LDPlayer also uses something apart from Magisk, i.e. SuperSu or similar.
Can confirm that changing the developer options as stated above worked perfectly. The backup completes correctly, and restores correctly on the target. Tested with two applications - Guardian Tales and Soul Knight (more details below)
I'm using LDPlayer because I can have both it and my current ROM running at the same time, so I can test porting things over without having to reflash and restore backups from google play. I have yet to see if there are any issues with different android versions, just trying things out at this point. I'll update in the future with results.
The operation appears to have completed flawlessly.
The issue: New ROM (iodeOS is using MicroG services, which do not support google play games (at the moment)
Solution: Restore progress from google play games on a separate device/ROM that has full gapps support, make a NeoBackup, and copy that to the new device
Step 1: Restore google play progress
Rather than reflashing my phone to stock ROM or messing with the possibility of dual boot, I figured I'd at least try out an emulator. After a little research, I settled on LDPlayer. It has a simple option to enable root- just go settings > advanced > Root [Enable]
. Simply go to the google play store and install the application, and restore the cloud progress in the way specific to that application.
Note that even though LDPlayer was on android 9, everything worked perfectly.
Step two: Install NeoBackup
I installed NeoBackup from f-droid, that way it would be the same version as on my physical device. Installation worked as normal- a window will appear to ask you to grant NeoBackup superuser perms. I chose forever.
Once I finished that, I made sure to set up the shared folder (shift + f5 in LDPlayer) so that all files/dirs under /sdcard/Pictures
would be synced to a folder on my desktop. I then created the folder /sdcard/Pictures/NeoBackup
, and set the NeoBackup app to use that for backups.
Step three: Make backups
Since LDP uses SuperSu or similar, I went to NB settings > Advanced > (Scroll down) Developer settings > backupTarCmd [Disable]
After that, I made a backup of everything except the APK.
Step four: copy neobackup files to new device
I won't go into details since your approach may be different, but I used adb push ./NeoBackup/* /sdcard/NeoBackup/
. /sdcard/NeoBackup
is the folder which is set up on my physical device as the NB backups folder. Note the trailing /
- this means to copy the source (using *
to say all files/dirs in the NeoBackup folder) into the folder as the destination.
I used the trailing slash, YYMV.
Step five: Restore
I installed the applications I desired (Soul Knight, Guardian Tales) on the physical device using the appropriate app store (in my case Aurora store), so that the version would be correct. I have had issues in the past with downloading an APK on one device and it not working on another, so I did this as opposed to copying the entire APK over via NB.
I rebooted the phone just to be safe, and then used NB to restore the data. Both applications worked perfectly, and retained my login information. Depending on the app, YYMV.
Edt: Forgot to mention- the target physical device was running iodeOS 3.2, using a modified version of MicroG. Android version 12.
I have had issues in the past with downloading an APK on one device and it not working on another
this is usual the case when the architecture is different, e.g. 32bit arm vs. 64bit etc., though the problem only exists for apps that use native code in some way (often the app has a lib folder then).
I already have a solution to support more su implementations, they only need to support the simple command line su 0
(or su --mount-master 0
if it exists) and this command must give access to directories like /data/user/0/
etc. (so no mount isolation takes place or similar technics or they are overridden by the root method in some way).
In an upcoming pumpkin version or later in neo (alpha, beta, rc) this should be included.
please test this:
[EDIT: new version] https://t.me/neo_backup/42590
I think it will work with more/most/all? su implementations now.
be careful, only use on test data, read the message (and the disclaimer)
new version for testing: https://t.me/neo_backup/42590
I guess it's solved...
I installed version 8.1.3 on my OnePlus 5 running LineageOS 16. I am able to backup APKs of applications but cannot backup data. Whenever I try to backup data of any app, I get the error in the attached screenshot.
Version 7.0.0 of the application was working fine on this device.