3

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.

maazkalim
  • 39
  • 5
  • 2
    com.qualcomm.timeservice is 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. – Robert Feb 10 '23 at 08:05
  • Ahh.. Hey, Mr "@Robert"! Here we 'meet' a-gain. Hope you're doing well. No I am asking with utmost sincerity.⏎Alright.. So I guess back to my irregularly-accessible PC then? (Since the apps like jackpal.androidterm function 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? – maazkalim Feb 11 '23 at 03:10
  • P.S. Okay, Mr @Robert .. I had to struggle since past innumerable hours in innumerable sessions, since it turns out, in ascending-order of my misery: A) The adb.exe, a-gain download as part of standalone SDK platform-tools kit, 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 .ab file 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, ... – maazkalim Feb 13 '23 at 11:04
  • ...given my jinx, after all. It turns that the PC I'm able to irregularly access had been deemed as "high-tech" as it is ancient( quarter-past-11-years as I "add" this) had been thoroughly rid of Java®, so I couldn't access any .jar file — as mandated by your tool. So I tried to install that "bestest-ever, open-source Java" programme from that .net official-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, the – maazkalim Feb 13 '23 at 11:11
  • bandwidth-allowance for a single, ubiquitous step in the ongoing voyage. C) After having installed it, it took my devraj m several tens-of-minutes to learn how to deploy the abe.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 .ab file, your recommended-tool turned-out to be profoundly useless for editing .tar aka, a misnomer of sorts. Since the conditions weren't conducive to me, I didn't have umpteenth hours to go find... – maazkalim Feb 13 '23 at 11:17
  • ...and learn if there's some way either of cmd.exe, the former or Java® could help in editing .tar folders as pre-installed freemium WinRAR® was oh-so-surprisingly appeared cruel towards us in that month. So I had no choice but to put my research-skills into motion yet a-gain, and finally found a sorta-reliable tool going by peazip.exe which did the trick through one of the 3 baffling deletion-types, since the rest of 2 were about deleting the whole .tar in and of itself which I had managed to extract after so much chore. D) So I managed to repack the updated .tar into .adb after – maazkalim Feb 13 '23 at 11:22
  • since minutes of trial-&-error( did I miss nothing that useful-enough PeaZip® was showing all folders as literally of “0KB” of size vis-à-vis utterly-useless WinRAR.exe, including but not limited to the com.qualcomm.timeservice one you overtly asked me to delete( there were other com.qualcomm.[…] folders which I've no qualms to admit, was I significantly inclined towards ridding of them all but I guess to enhance my misery further down the order, I stuck to only-&-only "following down the orders like a robot/institutional-drone of neoliberal world-order. But waiiittt..! This was no-... – maazkalim Feb 13 '23 at 11:32
  • ...-thing halfway through the mission. E) as the events summarised in point ‘A)’ kicked into action and restarting/shutting-down the PC didn't help it at all. F) Now I've installed the Android® Studio's .exe given the recurrence of Access is denied. errors with platform-tools only SDK, and after downloading and installing about fucking ~1GB of a file, turns out it was a mere shell( not necessarily in IT connotations) as I had to install discretionally needed "plugins" for total 3 so-called AOSP [sub-]releases given both of my phones, for starters. It took additional several-hours since – maazkalim Feb 13 '23 at 11:39
  • the whole carefully-selected once-&-all combo installation was of fatherfucking ~6¼GB in total-size, thereby bringing the total bandwidth-allowance spent for this last-resort tool to — by all conservative-estimates, quarter-past-7GBs alone. And for perspective, dare I remind that considering the timeline of this saga which started over from XDA® Developers' message-board to the here-&-now, a simplistic number-crunching still won't be able to di y quantifiable justice. Now I'm indescribably more-than-done with this, if this adb restore is not good. To fuck with brothafucking cockknuckle – maazkalim Feb 13 '23 at 11:45
  • Sorry, but I stopped reading after your 2nd comment. You are writing way too much and with too many fill words and irrelevant side facts. Please keep focused and your problem and the commands you executed. – Robert Feb 13 '23 at 12:15
  • My aplogies for your bother, then. All of the relevant commands have been already churned-out. But given your intolerance for proper-contextualisation, I guess I can offer you nothing besides that once a-gain, downloading-&-installing-&-then-repeat-cycle-for-3-AOSP-releases Android® Studio meant running PowerShell-7.3.2-win-x64.msi in-folder within the platform-tools sub-folder hidden inside Android folder of hidden root-folder AppData came across like the Best choice. And it was quite more helpful in suggesting corrections than MSDOS-era Command Prompt ever has been. Nothing else, IG? – maazkalim Feb 14 '23 at 02:59
  • running powershell.exe v5.1 in-folder within the sub-subfolder platform-tools, itself under the sub-folder Local within the folder Sdk of main-folder Android within the hidden AppData root-folder came* There! FTFM ‍♂️ Nothing latest except the fact that in cookie-cutter length, that I've created a single .txt file of .\adb.exe logcat with the added-bonus of -v -time suffixed-in there, for at least the last 2 restoration attempts. Thought given my STML-addled memory, think I could give an idea as to how USB link suddely disconnects-&-immediately-reconnects that way. – maazkalim Feb 14 '23 at 18:59

0 Answers0