This is a follow-up troubleshooting question to this one here in this very same forum.
After repeatedly confirming the connection through both of adb devices -l and fastboot devices -l tantamounting to at least ~5½ of overall sessions for the restore command of a 7.95GB-heavy backup file, whenever there's a successful prompt after proper command-execution of the following:
adb restore <filepath>
But I managed to notice the constant: The restoration always gets stuck on com.qualcomm.timeservice quite oddly till time-immemorial, since I understand that I might be at fault somehow, somewhere — but in spite of that, if the latest builds of so-called AOSP do not support alarm-ringing during device shutdown [not caused by battery-drainage], I can safely conclude that the alarm did work during switch-off state of my device at least once. Doesn't that translate to the package working fine, instead of having gone corrupt by the time I created the .ab file?
More details for those who un-stereotypically can digest in-depth text, they may get better context over there with some back-citation to key comments in that preceding question over here.
But other than the exact package which gets stuck, I should also note that I did try adb push <PC's .ab filepath> <device's root-directory path> after 1-2 trials-&-errors to determine which one is exactly it. It went upto 100% in ADB Enabled recovery mode, and then.. Failed to be stored by the time I booted the device last-time I clean-reinstalled the latest-build[ as I originally send this] of LineageOS 19.
The rest of the context is summarised there, except that I haven't tried bmgr of adb shell 'cus using bu help wasn't much of a help, so it slipped my mind to try creating backup through that method — nevermind restoring.
com.qualcomm.timeserviceis an internals service you don't need to recover. I would extract the backup data using abe, delete the data for this package, rebuild the backup file and try again to recover the data.jackpal.androidtermfunction properly on rooted-devices only, no?) Also, is not locking the bootloader [as of] yet — a good-thing, no? Is it insignificant/immaterial/irrelevant? And do I have to create a newer backup-file and necessarily wipe the cache and system partitions, if not necessarily a wholesome clean-reinstall for the 6½th time?adb.exe, a-gain download as part of standalone SDKplatform-toolskit, had gone wholesomely corrupt but unlike the in-depth explanation at XDA, it hadn't reduced to "0KB" or anywhere remotely-near it. B) If it helps, frighteningly, turns out the very same case was with my.abfile in question — but I managed to 'miraculously' recover it full-&-proper when I regained my composure. C) One bad, one good — you say? Not that soon, ....jarfile — as mandated by your tool. So I tried to install that "bestest-ever, open-source Java" programme from that.netofficial-web but in spite of installing the certificate separately, I still couldn't get it to installation. So we went to the OGs, ~~Sun® Microsystems~~ Oracle® and after having expended twice the amount of time and more importantly, theabe.jar[ through Windows® PowerShell® from the "Downloads" folder"] within the hostile/unhelpful environment taking the toll on my mind, and when I finally managed to do so i.e. convert that successfully-recovered.abfile, your recommended-tool turned-out to be profoundly useless for editing.taraka, a misnomer of sorts. Since the conditions weren't conducive to me, I didn't have umpteenth hours to go find...