On 2024-11-07 14:17, Java Jive wrote:
>
> 2 I think this might be the same one as you reach by the path you gave
> above.  It is a single switch option which was already enabled, and is
> fully described thus:
>
> "Back up your device data and app data automatically to Google Drive
> (including WiFi passwords, the Phone log, app settings, and related files.
>
> App data may include personal information such as contacts, messages,
> and pictures."
>
> If I could find out how to restore only the WiFi settings from that to a
> different phone, I guess I'd be home and dry, but I can't even find out
> how to use it to restore to the *SAME* phone that it was made from.

Now that Google Drive is enabled and functional on both devices, both
have made a backup, each of which the other can see listed, but, even on
the same device as made the backup, you can't actually *DO* anything
with these backups, other than delete them.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive <java@evij.com.invalid> wrote:
> On 2024-11-07 14:17, Java Jive wrote:
> >
> > 2 I think this might be the same one as you reach by the path you gave
> > above.  It is a single switch option which was already enabled, and is
> > fully described thus:
> >
> > "Back up your device data and app data automatically to Google Drive
> > (including WiFi passwords, the Phone log, app settings, and related files.
> >
> > App data may include personal information such as contacts, messages,
> > and pictures."
> >
> > If I could find out how to restore only the WiFi settings from that to a
> > different phone, I guess I'd be home and dry, but I can't even find out
> > how to use it to restore to the *SAME* phone that it was made from.
>
> Now that Google Drive is enabled and functional on both devices, both
> have made a backup, each of which the other can see listed, but, even on
> the same device as made the backup, you can't actually *DO* anything
> with these backups, other than delete them.

Ain't that great! Who needs restore?

Let me check my phone:

Settings -> Accounts and backup ->

"Samsung Cloud
Back up data (offers choices for what (not) to back up)
Restore data (offers choices for what (not) to restore)
('Settings' choice includes Wi-Fi settings!)

Google Drive
Back up data"
(has no restore section!)

What brand was your new phone again!?

Sorry, couldn't resist, just kidding.

On 2024-11-07 19:26, Frank Slootweg wrote:
> Java Jive <java@evij.com.invalid> wrote:
>> On 2024-11-07 14:17, Java Jive wrote:
>>>
>>> 2 I think this might be the same one as you reach by the path you gave
>>> above.  It is a single switch option which was already enabled, and is
>>> fully described thus:
>>>
>>> "Back up your device data and app data automatically to Google Drive
>>> (including WiFi passwords, the Phone log, app settings, and related files.
>>>
>>> App data may include personal information such as contacts, messages,
>>> and pictures."
>>>
>>> If I could find out how to restore only the WiFi settings from that to a
>>> different phone, I guess I'd be home and dry, but I can't even find out
>>> how to use it to restore to the *SAME* phone that it was made from.
>>
>> Now that Google Drive is enabled and functional on both devices, both
>> have made a backup, each of which the other can see listed, but, even on
>> the same device as made the backup, you can't actually *DO* anything
>> with these backups, other than delete them.
>
> Ain't that great! Who needs restore?
>
> Let me check my phone:
>
> Settings -> Accounts and backup ->
>
> "Samsung Cloud
> Back up data (offers choices for what (not) to back up)
> Restore data (offers choices for what (not) to restore)
> ('Settings' choice includes Wi-Fi settings!)

But no granularity, so you can't restore just one item or set of items
from the Settings, and you can't restore to a non-Samsung phone, and
perhaps even any phone other than the one that made the backup, though
I'm unsure of that last point.

> Google Drive
> Back up data"
> (has no restore section!)

Yes, ridiculous! Google seems to be keener on having your data to trawl
than actually allowing you, the owner of it, to use it meaningfully!
Presumably what is supposed to happen is that, if your phone gets wiped,
it will offer to restore from the last backup, but I'm not about to test
that by wiping my phone! Today's tests have reminded me why I always
had Google Drive disabled from the start.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive wrote:

> Presumably what is supposed to happen is that, if your phone gets wiped,
> it will offer to restore from the last backup

Yes, there have been a couple of times e.g. I've had a hardware fault on
a brand new phone, had to wipe it to exchange it for a replacement, and
hit the restore button, and it just does that (apart from software such
as K-9 which doesn't store config backups in the Google account)

> but I'm not about to test that by wiping my phone!

You've presumably got your old one that you could play with?

On 2024-11-07 17:18, Frank Slootweg wrote:
> A little earlier, I wrote:
>> That Wi-Fi passwords are not backed up 1) is not true for Samsungs's
>> Smart Switch (see above) and 2) for Google Backup (to Google Drive) has
>> been more or less debunked by my response of earlier today:
>
> N.B. Google Backup ('Backup by Google One') specifically says that
> Wi-Fi passwords are backed up.

On my Motorola phone, settings, search "Google backup" finds nothing.
Nor does "backup".

I have "copia de seguridad", and "copia de seguridad de Google One",
which must be it. It is as complete as it is, except for photos which I
disabled (I back them up to Amazon).

>
> On my (Samsung Galaxy A51) Android 13 phone:
>
> Settings -> Google / Google services -> All services -> Backup &
> restore -> Backup -> Manage storage -> opens one.google.com webpage ->
> YOUR DEVICE BACKUP (2) -> Galaxy A51 -> See details ->

Found it.

>
> "Device settings 208 KB
> Wallpaper, Wi-Fi password..."
>
> N.B. The part after "password" can not be shown, only gives the three
> dots, but if I go to the one.google.com webpage on my laptop, it says:
>
> "Device settings
> Wallpaper, Wi-Fi passwords and more"

Does not open.

>
> So Wi-Fi passwords are backed up by Google Backup. Whether they are
> also transferred from an old to a new device is still unanswered (by
> official references).
>
> [...]

--
Cheers,
Carlos E.R.

On 2024-11-07 21:01, Andy Burns wrote:
>
> Java Jive wrote:
>>
>> Presumably what is supposed to happen is that, if your phone gets
>> wiped, it will offer to restore from the last backup
>
> Yes, there have been a couple of times e.g. I've had a hardware fault on
> a brand new phone, had to wipe it to exchange it for a replacement, and
> hit the restore button, and it just does that (apart from software such
> as K-9 which doesn't store config backups in the Google account)
>
>> but I'm not about to test that by wiping my phone!
>
> You've presumably got your old one that you could play with?

Snakes And Ladders, or Catch 22, again - don't want to play with it
until I've extracted the WiFi logons!

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2024-11-07 17:18, Frank Slootweg wrote:
> > A little earlier, I wrote:
> >> That Wi-Fi passwords are not backed up 1) is not true for Samsungs's
> >> Smart Switch (see above) and 2) for Google Backup (to Google Drive) has
> >> been more or less debunked by my response of earlier today:
> >
> > N.B. Google Backup ('Backup by Google One') specifically says that
> > Wi-Fi passwords are backed up.
>
> On my Motorola phone, settings, search "Google backup" finds nothing.
> Nor does "backup".
>
> I have "copia de seguridad", and "copia de seguridad de Google One",
> which must be it. It is as complete as it is, except for photos which I
> disabled (I back them up to Amazon).
>
> >
> > On my (Samsung Galaxy A51) Android 13 phone:
> >
> > Settings -> Google / Google services -> All services -> Backup &
> > restore -> Backup -> Manage storage -> opens one.google.com webpage ->
> > YOUR DEVICE BACKUP (2) -> Galaxy A51 -> See details ->
>
> Found it.
>
> >
> > "Device settings 208 KB
> > Wallpaper, Wi-Fi password..."
> >
> > N.B. The part after "password" can not be shown, only gives the three
> > dots, but if I go to the one.google.com webpage on my laptop, it says:
> >
> > "Device settings
> > Wallpaper, Wi-Fi passwords and more"
>
> Does not open.

Exactly. My point was only that the Wi-Fi settings *are* backed up,
not that they are seperately accessible/restorable with other tools.

> > So Wi-Fi passwords are backed up by Google Backup. Whether they are
> > also transferred from an old to a new device is still unanswered (by
> > official references).

Java Jive <java@evij.com.invalid> wrote:
> On 2024-11-07 19:26, Frank Slootweg wrote:
[...]
> > Let me check my phone:
> >
> > Settings -> Accounts and backup ->
> >
> > "Samsung Cloud
> > Back up data (offers choices for what (not) to back up)
> > Restore data (offers choices for what (not) to restore)
> > ('Settings' choice includes Wi-Fi settings!)
>
> But no granularity, so you can't restore just one item or set of items
> from the Settings, and you can't restore to a non-Samsung phone, and
> perhaps even any phone other than the one that made the backup, though
> I'm unsure of that last point.

Indeed, only useful for restoring to the same phone or a replacement
(Samsung) phone.

> > Google Drive
> > Back up data"
> > (has no restore section!)
>
> Yes, ridiculous! Google seems to be keener on having your data to trawl
> than actually allowing you, the owner of it, to use it meaningfully!
> Presumably what is supposed to happen is that, if your phone gets wiped,
> it will offer to restore from the last backup, but I'm not about to test
> that by wiping my phone! Today's tests have reminded me why I always
> had Google Drive disabled from the start.

Yes, the Google backup can probably restored to the same device and,
as Andy also indicated, the Google backup can be restored to a new
phone. That's described by following the links on the Google One
(one.google.com) site:

-> Backup -> Back up your device -> Lern more ->

'Back up your device'
<https://support.google.com/googleone/answer/9149304>
(select 'Android' tab if not preselected)
"...
Get your data onto a new phone

Your photos and videos are already available in Google Photos. You can
restore your backed up data when you set up your new device for the
first time or after you set up your device.

* At setup, to restore your data, follow the on-screen steps.
..."

The detailed instructions are mostly for Google Pixel phones, but I
think other brands have similar capability.

At the time, 4 years ago, my Samsung phone only presented the
(Samsung) Smart Switch procedure, but perhaps the Google restore method
was available somewhere else, like in Settings.

Bottom line: It's still strange that also this ('Back up your device')
document doesn't say anything about restoring to the *same* ('old')
phone.

Andy Burns <usenet@andyburns.uk> wrote:
> Java Jive wrote:
>
> > Presumably what is supposed to happen is that, if your phone gets wiped,
> > it will offer to restore from the last backup
>
> Yes, there have been a couple of times e.g. I've had a hardware fault on
> a brand new phone, had to wipe it to exchange it for a replacement, and
> hit the restore button, and it just does that (apart from software such
> as K-9 which doesn't store config backups in the Google account)

In my experience *most* (non-Google) software doesn't store
configuration settings in the Google account (or Google Drive). They
(have to) store it in their app-private area (Android\data, etc.) which
means that general purpose backup programs can not access it and hence
can not back it up.

This is really a pain, because you have to 'export' (*if* such a
function is available in the app) app-private settings from each and
every non-Google app to some common area, before you can back it up. Not
to mention not being able to backup app-private data.

That said, do *you* have any positive experience that the Google
restore method restores the *data* of non-Google apps (i.e. for example
to local mail copies of K-9 Mail)?

> > but I'm not about to test that by wiping my phone!
>
> You've presumably got your old one that you could play with?

Luckily, I've not yet needed to restore any stuff which I could not
backups, but that's mostly because my old phone had Android 5.1.1, so
the app-private areas still *could* be backed up by convential methods,

Java Jive wrote:

> Andy Burns wrote:
>
>> You've presumably got your old one that you could play with?
>
> Snakes And Ladders, or Catch 22, again  -  don't want to play with it
> until I've extracted the WiFi logons!
Create a virtual phone within Android Studio and play with that instead?

On 2024-11-08 10:39, Frank Slootweg wrote:
> Carlos E. R. <robin_listas@es.invalid> wrote:
>> On 2024-11-07 17:18, Frank Slootweg wrote:
>>> A little earlier, I wrote:
>>>> That Wi-Fi passwords are not backed up 1) is not true for Samsungs's
>>>> Smart Switch (see above) and 2) for Google Backup (to Google Drive) has
>>>> been more or less debunked by my response of earlier today:
>>>
>>> N.B. Google Backup ('Backup by Google One') specifically says that
>>> Wi-Fi passwords are backed up.
>>
>> On my Motorola phone, settings, search "Google backup" finds nothing.
>> Nor does "backup".
>>
>> I have "copia de seguridad", and "copia de seguridad de Google One",
>> which must be it. It is as complete as it is, except for photos which I
>> disabled (I back them up to Amazon).
>>
>>>
>>> On my (Samsung Galaxy A51) Android 13 phone:
>>>
>>> Settings -> Google / Google services -> All services -> Backup &
>>> restore -> Backup -> Manage storage -> opens one.google.com webpage ->
>>> YOUR DEVICE BACKUP (2) -> Galaxy A51 -> See details ->
>>
>> Found it.
>>
>>>
>>> "Device settings 208 KB
>>> Wallpaper, Wi-Fi password..."
>>>
>>> N.B. The part after "password" can not be shown, only gives the three
>>> dots, but if I go to the one.google.com webpage on my laptop, it says:
>>>
>>> "Device settings
>>> Wallpaper, Wi-Fi passwords and more"
>>
>> Does not open.
>
> Exactly. My point was only that the Wi-Fi settings *are* backed up,
> not that they are seperately accessible/restorable with other tools.

Not "exactly". Mine does not say what it stores. It doesn't say it
stores wifi passwords. It just says "device settings".

--
Cheers,
Carlos E.R.

On 2024-11-07 17:35, Andrews wrote:
> Java Jive wrote on Thu, 7 Nov 2024 17:02:06 +0000 :
>
>>> I assume you tried copying it already when I gave the commands necessary.
>>
>> 16:44:31 D:\Temp>C:\Programs\Samsung\platform-tools\adb.exe root
>
> Thanks for running the suggested test!
>
> I'm surprised that command didn't give an error as mine did on my unrooted
> Android 13 Galaxy - but I do not know what "adb root" even does.
>
> Running a search for what does adb root do this comes up
> <https://duckduckgo.com/?va=d&t=hf&q=what+does+adb+root+do>
>
> *Understanding adb shell su and adb root Commands*
> <https://www.repeato.app/understanding-adb-shell-su-and-adb-root-commands/>
> "the command adb root restarts the adb daemon with root permissions,
> allowing you to execute ADB commands as root without entering the shell."
>
> Since your "adb root" works, my suggestion is that you may be able to...
> 1. adb pull the WifiConfigStore.xml file from Android to Windows
> 2. Edit it on Windows any way you like
> 3. adb push that now-edited WifiConfigStore.xml back to Android
>
>> 16:45:56 D:\Temp>C:\Programs\Samsung\platform-tools\adb.exe pull
>> /data/misc/apexdata/com.android.wifi/WifiConfigStore.xml
>> adb: error: remote object
>> '/data/misc/apexdata/com.android.wifi/WifiConfigStore.xml' does not exist
>>
>> 16:46:09 D:\Temp>
>>
>> There is a data directory visible in explorer under ...
>>
>> /Internal storage/Android
>>
>> ... but adding that to the beginning of the path makes no odds, and in
>> fact trying to pull a file that I know exists, because I can see it in
>> Explorer, also fails:
>>
>> 16:54:31 D:\Temp>C:\Programs\Samsung\platform-tools\adb.exe pull
>> "/Internal
>> storage/Android/data/com.android.systemui/cache/lockscreen_capture_land.png"
>> adb: error: remote object '/Internal
>> storage/Android/data/com.android.systemui/cache/lockscreen_capture_land.png'
>> does not exist
>>
>> Make of that what you will, remembering that I don't believe this device
>> is rooted, although the adb root command seemed to work.

> [snip]
>
> My advice is that since you can use the "adb root" command, that you can
> almost certainly "adb pull" and "adb push" the WifiConfigStore.xml file.
>
> You just have to find it first. :)

As far as I have been able to establish, it's just not there.

There is a command ...
<path>\adb backup
.... which creates a backup of the phone or tablet on your computer.
However, the backup so created, called backup.ab, is a unique tar file
format that almost nothing else can read as is, though there are neat
workarounds as long as it is not encrypted; however, because my tablet
is encrypted, so is the backup, which means that the simple workarounds
don't work.

A whole Perl upgrade later, where the biggest problem was actually
uninstalling the previous version, to run a Perl script to extract the
contents resulted only in a message that it couldn't do anything with
this version 4, a version later than that for which it was written.

A whole Java upgrade later, where again the biggest problem was
uninstalling the previous JDK and JRE, finally extracted it, but it
seems to contain nothing useful that was not available already simply by
connecting the phone to the PC in the normal way.

There is a command ...
<path>\adb shell ls
.... which lists the root, I presume, directory as ...
acct
bugreports
cache
carrier
config
d
data
default.prop
dev
dsp
efs
etc
file_contexts.bin
firmware
firmware-modem
fstab.qcom
init
init.carrier.rc
init.class_main.sh
init.container.rc
init.environ.rc
init.mdm.sh
init.qcom.bms.sh
init.qcom.class_core.sh
init.qcom.early_boot.sh
init.qcom.factory.rc
init.qcom.rc
init.qcom.sh
init.qcom.syspart_fixup.sh
init.qcom.usb.rc
init.qcom.usb.sh
init.rc
init.recovery.qcom.rc
init.rilchip.rc
init.target.rc
init.usb.configfs.rc
init.usb.rc
init.wifi.rc
init.zygote32.rc
init.zygote64_32.rc
knox_data
mnt
oem
persdata
persist
postrecovery.do
preload
proc
property_contexts
publiccert.pem
root
sbin
sdcard
seapp_contexts
sepolicy
sepolicy_version
service_contexts
storage
sys
system
tombstones
ueventd.qcom.rc
ueventd.rc
vendor
verity_key
.... which allows the following batch command to be run ...
for /f "usebackq tokens=*" %A in (`<path>\adb shell ls`) do @if not
%A==proc <path>\adb pull /%A
.... and I'm currently waiting for the /sys directory to complete, but a
search of those completed so far has found nothing of interest in the
others.

I think the truth is the same as with all the other attempts, because
the tablet is not rooted, the information I want is not available to me.

Scandalous, really.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Frank Slootweg wrote on 8 Nov 2024 10:47:57 GMT :

> In my experience *most* (non-Google) software doesn't store
> configuration settings in the Google account (or Google Drive). They
> (have to) store it in their app-private area (Android\data, etc.) which
> means that general purpose backup programs can not access it and hence
> can not back it up.

This is for everyone not so much for Frank as I'm sure Frank knows this.

Regarding where apps store their data, (some apps, not all, not even most
perhaps, but some apps) will store data onto the users' external sd card.

For those programs, what I do is format the external sd card with a known
volume label (e.g., 0000-0001) which allows me to pull out that sd card and
put it into another phone which is "expecting" the data in that location.

Works every time... Which makes me wonder...

Why not pull out that sdcard and copy it on Windows to fully back it up?
I don't normally do that because I don't need to, but wouldn't that work?

Summary:
Q: Would it work to back up an external sdcard to simply "copy" it?
A: ?

Note I'm aware that won't work for fundamental operating system files which
are stored on sdcard0 and not stored on the external sdcard - but still...

On 2024-11-09 00:08, Java Jive wrote:
>
> There is a command ...
>   <path>\adb backup
> ... which creates a backup of the phone or tablet on your computer.
> However, the backup so created, called backup.ab, is a unique tar file
> format that almost nothing else can read as is, though there are neat
> workarounds as long as it is not encrypted; however, because my tablet
> is encrypted, so is the backup, which means that the simple workarounds
> don't work.
>
> A whole Perl upgrade later, where the biggest problem was actually
> uninstalling the previous version, to run a Perl script to extract the
> contents resulted only in a message that it couldn't do anything with
> this version 4, a version later than that for which it was written.
>
> A whole Java upgrade later, where again the biggest problem was
> uninstalling the previous JDK and JRE, finally extracted it, but it
> seems to contain nothing useful that was not available already simply by
> connecting the phone to the PC in the normal way.

Actually they were there all along, which shows just how useless is
Windows Search, by contrast Textpad's Find in Files option found them.

So, the full procedure is:

1. <path>\adb backup

.... creates backup.ab in the current directory

2. Install or update to the latest Java Runtime Environment,
currently 1.8.0_431:

https://www.java.com/en/download/help/download_options.html

3. Download Nelenkov's abe*.jar file:

https://github.com/nelenkov/android-backup-extractor
https://github.com/nelenkov/android-backup-extractor/releases/download/latest/abe-3e9a273.jar

Give the command (without the square brackets around the password, they
are merely a convention signifying that it is an optional parameter):

java -jar <path>\abe-3e9a273.jar unpack <path>\backup.ab
<path>\backup.tar [password]

The resulting tar file can be extracted by 7-zip. Search the extracted
files' contents for an SSID known to be on the device, mine were in:

\apps\com.android.providers.settings\d_f\flattened-data

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On 2024-11-09 01:01, Java Jive wrote:
> On 2024-11-09 00:08, Java Jive wrote:
>>
>> There is a command ...
>>    <path>\adb backup
>> ... which creates a backup of the phone or tablet on your computer.
>> However, the backup so created, called backup.ab, is a unique tar file
>> format that almost nothing else can read as is, though there are neat
>> workarounds as long as it is not encrypted; however, because my tablet
>> is encrypted, so is the backup, which means that the simple
>> workarounds don't work.
>>
>> A whole Perl upgrade later, where the biggest problem was actually
>> uninstalling the previous version, to run a Perl script to extract the
>> contents resulted only in a message that it couldn't do anything with
>> this version 4, a version later than that for which it was written.
>>
>> A whole Java upgrade later, where again the biggest problem was
>> uninstalling the previous JDK and JRE, finally extracted it, but it
>> seems to contain nothing useful that was not available already simply
>> by connecting the phone to the PC in the normal way.
>
> Actually they were there all along, which shows just how useless is
> Windows Search, by contrast Textpad's Find in Files option found them.
>
> So, the full procedure is:
>
> 1.    <path>\adb backup
>
> ... creates backup.ab in the current directory
>
> 2.    Install or update to the latest Java Runtime Environment,
> currently 1.8.0_431:
>
> https://www.java.com/en/download/help/download_options.html
>
> 3.    Download Nelenkov's abe*.jar file:
>
> https://github.com/nelenkov/android-backup-extractor
> https://github.com/nelenkov/android-backup-extractor/releases/download/latest/abe-3e9a273.jar
>
> Give the command (without the square brackets around the password, they
> are merely a convention signifying that it is an optional parameter):
>
> java -jar <path>\abe-3e9a273.jar unpack <path>\backup.ab
> <path>\backup.tar [password]
>
> The resulting tar file can be extracted by 7-zip.  Search the extracted
> files' contents for an SSID known to be on the device, mine were in:
>
> \apps\com.android.providers.settings\d_f\flattened-data

Should have added my thanks to all those who have helped along the way.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On 2024-11-09 00:08, Java Jive wrote:
>
> There is a command ...
>   <path>\adb shell ls
> ... which lists the root, I presume, directory as ...
>   acct
>   bugreports
>   cache
>   carrier
>   config
>   d
>   data
>   default.prop
>   dev
>   dsp
>   efs
>   etc
>   file_contexts.bin
>   firmware
>   firmware-modem
>   fstab.qcom
>   init
>   init.carrier.rc
>   init.class_main.sh
>   init.container.rc
>   init.environ.rc
>   init.mdm.sh
>   init.qcom.bms.sh
>   init.qcom.class_core.sh
>   init.qcom.early_boot.sh
>   init.qcom.factory.rc
>   init.qcom.rc
>   init.qcom.sh
>   init.qcom.syspart_fixup.sh
>   init.qcom.usb.rc
>   init.qcom.usb.sh
>   init.rc
>   init.recovery.qcom.rc
>   init.rilchip.rc
>   init.target.rc
>   init.usb.configfs.rc
>   init.usb.rc
>   init.wifi.rc
>   init.zygote32.rc
>   init.zygote64_32.rc
>   knox_data
>   mnt
>   oem
>   persdata
>   persist
>   postrecovery.do
>   preload
>   proc
>   property_contexts
>   publiccert.pem
>   root
>   sbin
>   sdcard
>   seapp_contexts
>   sepolicy
>   sepolicy_version
>   service_contexts
>   storage
>   sys
>   system
>   tombstones
>   ueventd.qcom.rc
>   ueventd.rc
>   vendor
>   verity_key
> ... which allows the following batch command to be run ...
>   for /f "usebackq tokens=*" %A in (`<path>\adb shell ls`) do @if not
> %A==proc <path>\adb pull /%A
> ... and I'm currently waiting for the /sys directory to complete, but a
> search of those completed so far has found nothing of interest in the
> others.

FWIW, the /sys folder never completed, eventually aborting, so I suspect
that, like the /proc folder, it contains circular links - I only
noticed those in the latter folder because they were sockets which gave
rise to ever lengthening error messages, whereas the /sys folder just
kept churning on. This means that the command above should read:

for /f "usebackq tokens=*" %A in (`<path>\adb shell ls`) do @if not
%A==proc if not %A==sys <path>\adb pull /%A

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Without line wrap, let's see if this comes out better:

for /f "usebackq tokens=*" %A in (`<path>\adb shell ls`) do @if not
%A==proc if not %A==sys <path>\adb pull /%A

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive wrote on Sat, 9 Nov 2024 01:15:55 +0000 :

> Should have added my thanks to all those who have helped along the way.

We're all here to help each other - and to give back to the team.
We've been doing this for decades - as we're kind hearted helpful people.

Helping you has taught me things as I've never used "adb backup" myself.
Never even heard of it.

It's GREAT that you resolved the question of extracting (and restoring?)
Wi-Fi passwords on older Androids (which didn't lock WifiConfigStore.xml).

I'm trying to reproduce steps but I'm not sure the sequence on Android 13.

C:\app\editor\android\scrcpy> adb backup
WARNING: adb backup is deprecated and may be removed in a future release
adb.exe: backup either needs a list of packages or -all/-shared

C:\app\editor\android\scrcpy> adb --version
Android Debug Bridge version 1.0.41
Version 33.0.3-8952118
Installed as C:\app\editor\android\scrcpy\adb.exe

Looking it up, I see there is an Android backup-and-restore guide.
<https://github.com/eviabs/Android-Backup-and-Restore-Guide/blob/master/Android%20Backup%20and%20Restore%20Guide.md>
"An *.ab backup contains all your personal and hidden data of your app.
It doesn't necessary contain your local storage data (which is located in
your sd card). Make sure you copy by yourself the sd card content."

C:\app\editor\android\scrcpy> adb backup -f myAndroidBackup.ab com.grindrapp.android
WARNING: adb backup is deprecated and may be removed in a future release
Now unlock your device and confirm the backup operation...
(My phone in another room popped up an unlock request, which I easily
accepted from Windows since I operate my phone at home from the PC.)

C:\app\editor\android\scrcpy> dir myAndroidBackup.ab
11/08/2024 11:40 PM 47 myAndroidBackup.ab

C:\app\editor\android\scrcpy> adb backup -apk -shared -all -f fullAndroidBackup.ab
(again the monitor dedicated to Android popped up an unlock request which
I accepted from the PC as I don't feel like looking for the phone)

It's taking a while... so moving on, here's how to restore apparently.

Single app backup (the app has to actually be installed already).
C:\app\editor\android\scrcpy> adb restore myAndroidBackup.ab

(I'm still waiting for the all-apps-and-their-data backup to finish.)
The only thing is these are restoring "apps", not Wi-Fi settings, right?

So I'm confused (although the "settings" app is just another app too).
How does this backup/restore Wi-Fi configuration settings?

Andrews wrote on Sat, 9 Nov 2024 04:54:25 -0000 (UTC) :

> How does this backup/restore Wi-Fi configuration settings?

Oops. Didn't see the Java jar stuff. Gonna try again...

But right now I'm waiting for the adb backup to finish.

It's taking a looooooooooong time but I have over 900 apps installed on my
phone (as I test apps against each other all the time) so it may take all
night.

Good think it's all being done from the PC while the phone is somewhere in
the room charging on a night table as I operate the phone from the PC.

Andrews wrote on Sat, 9 Nov 2024 04:57:08 -0000 (UTC) :

> It's taking a looooooooooong time but I have over 900 apps installed on my
> phone (as I test apps against each other all the time) so it may take all
> night.

The adb full backup finished. It took around a half hour or so (I didn't
time it though) but it's not a small backup file, that's for sure...

C:\app\editor\android\scrcpy> adb backup -apk -shared -all -f fullAndroidBackup.ab
C:\app\editor\android\scrcpy >dir *ab
Directory of C:\app\editor\android\scrcpy
11/08/2024 11:15 PM 10,589,970,522 fullAndroidBackup.ab
11/08/2024 10:40 PM 47 myAndroidBackup.ab

I have no idea (yet) what to do with that "full backup"; but it worked.
Does anyone have a working process to use these adb full backups?

And I still have to try the java stuff for the Wi-Fi passwords.

But every time I touch java on Windows, I have to install tons of crapware.
So I'm gun shy....

On 2024-11-09 01:01, Java Jive wrote:

In response to Andrews' comments, I think I need to clarify these. In
particular, the adb command given is probably wrong, because, after all
the attempts to uninstall and reinstall Perl and Java the actual command
I gave had fallen off the end of the DOSKey list, so I wrote it, late
last night, from memory. However, I got it from here and can now tell
that I must have misremembered it (312-314):

https://gist.github.com/Pulimet/5013acf2cd5b28e55036c82c91bd56d8

So the (corrected) full procedure is:

1. <path>\adb backup -all -f backup.ab

.... creates backup.ab in the current directory

2. Install or update to the latest Java Runtime Environment,
currently 1.8.0_431:

https://www.java.com/en/download/help/download_options.html

3. Download Nelenkov's abe*.jar file:

https://github.com/nelenkov/android-backup-extractor
https://github.com/nelenkov/android-backup-extractor/releases/download/latest/abe-3e9a273.jar

4. Give the command (without the square brackets around the password,
they are merely a convention signifying that it is an optional parameter):

java -jar <path>\abe-3e9a273.jar unpack <path>\backup.ab
<path>\backup.tar [password]

5. The resulting tar file can be extracted by 7-zip.

6. Search the contents of the extracted files for an SSID known to be
on the device, mine were in:

\apps\com.android.providers.settings\d_f\flattened-data

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Andrews wrote on Sat, 9 Nov 2024 04:54:25 -0000 (UTC) :

> Single app backup (the app has to actually be installed already).
> C:\app\editor\android\scrcpy> adb restore myAndroidBackup.ab

Bear in mind, for those who don't already know it, Android *never* deletes
the actual installer that was used to install an app, so it's there.

You just have to find it.

Also, note it's far easier to manage Android from Windows than from the
phone (for so many obvious reasons, I won't even list them for you).

So let's assume we want a backup on Windows of osmand~ *and* its data.

First you have to find the package name if you don't already know it.
C:\> adb shell pm list packages | findStr /i "osmand"
package:net.osmand.plus

Then you have to find the location of the APK stored on your phone.
C:\> adb shell pm path net.osmand.plus
package:/data/app/~~k-jK7n2qHWcW_giNy6oVEA==/net.osmand.plus-6ws8wQWIkEi8vVgL5q3EdA==/base.apk

Then you can copy that APK manually if that's what you really want to do.
C:\> adb pull /data/app/~~k-jK7n2qHWcW_giNy6oVEA==/net.osmand.plus-6ws8wQWIkEi8vVgL5q3EdA==/base.apk

Since *every* stored APK on Android is named, "base.apk", rename it:
C:\> move base.apk net.osmand.plus_bck.apk

But nobody would copy an apk that way (unless they're writing scripts).
That's why they made all those free Android APK extraction tools.
<https://play.google.com/store/apps/details?id=de.onyxbits.listmyapps>
<https://play.google.com/store/apps/details?id=com.jenos.shareapkfile>
<https://play.google.com/store/apps/details?id=sk.styk.martin.apkanalyzer>

Now that you have the APK backed up, it's time to use adb's data backup:
C:\> adb backup -f net.osmand.plus_bck.ab net.osmand.plus
WARNING: adb backup is deprecated and may be removed in a future release
Now unlock your device and confirm the backup operation...

Now you have both the installer & the data on your Windows system:
C:\> dir *osmand*
11/09/2024 05:45 AM 146,644,539 net.osmand.plus_bck.apk
11/09/2024 05:50 AM 47 net.osmand.plus_bck.ab

Note that I'm not sure what is in that data ball of string since the help
for adb backup says you need to copy over some things manually from your
sdcard. I suspect that's the internal sdcard they were referring to since
some people don't have an external sdcard.

To find where sdcard information is installed, I will *guess* it's in the
information that is spit out with a query using adb. Maybe this query?
C:\> adb shell pm dump net.osmand.plus > net.osmand.plus_bck.txt

That file is over eight thousand lines long, so I'm not sure if it tells us
where the map data is stored & whether or not that's backed up.

Anyone know how to find the map data for osmand if it's stored on your
external sdcard? (Of course, you know where you put it - but this is for
general use where the user is backing up a device so they might not know.)

Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2024-11-08 10:39, Frank Slootweg wrote:
> > Carlos E. R. <robin_listas@es.invalid> wrote:
> >> On 2024-11-07 17:18, Frank Slootweg wrote:
> >>> A little earlier, I wrote:
> >>>> That Wi-Fi passwords are not backed up 1) is not true for Samsungs's
> >>>> Smart Switch (see above) and 2) for Google Backup (to Google Drive) has
> >>>> been more or less debunked by my response of earlier today:
> >>>
> >>> N.B. Google Backup ('Backup by Google One') specifically says that
> >>> Wi-Fi passwords are backed up.
> >>
> >> On my Motorola phone, settings, search "Google backup" finds nothing.
> >> Nor does "backup".
> >>
> >> I have "copia de seguridad", and "copia de seguridad de Google One",
> >> which must be it. It is as complete as it is, except for photos which I
> >> disabled (I back them up to Amazon).
> >>
> >>>
> >>> On my (Samsung Galaxy A51) Android 13 phone:
> >>>
> >>> Settings -> Google / Google services -> All services -> Backup &
> >>> restore -> Backup -> Manage storage -> opens one.google.com webpage ->
> >>> YOUR DEVICE BACKUP (2) -> Galaxy A51 -> See details ->
> >>
> >> Found it.
> >>
> >>>
> >>> "Device settings 208 KB
> >>> Wallpaper, Wi-Fi password..."
> >>>
> >>> N.B. The part after "password" can not be shown, only gives the three
> >>> dots, but if I go to the one.google.com webpage on my laptop, it says:
> >>>
> >>> "Device settings
> >>> Wallpaper, Wi-Fi passwords and more"
> >>
> >> Does not open.
> >
> > Exactly. My point was only that the Wi-Fi settings *are* backed up,
> > not that they are seperately accessible/restorable with other tools.
>
> Not "exactly". Mine does not say what it stores. It doesn't say it
> stores wifi passwords. It just says "device settings".

But you said "Does not open.", so did or did you not get the

> >>> "Device settings
> >>> Wallpaper, Wi-Fi passwords and more"

message?

Note that this message is on the one.google.com *webpage*, not in the
Settings (sub-)menu itself. I.e. it comes from a the website, not from
your phone itself. So you *see* the message on your *phone*, but it
*comes from* the one.google.com *webserver*.

To be sure, just go to the one.google.com webpage on your computer and
follow the instructions, which I gave earlier:

-> Backup -> View -> "YOUR DEVICE BACKUP ..." -> select your device ->
See details ->

"<your device name>

Last backup: ...
...
Backup details
...
Device settings NNN KB
Wallpaper, Wi-Fi passwords and more
..."

If you do not get this message (with "Wi-Fi passwords", then please
post what the "Backup details" page on your computer *does* say.