• Backing up your mobile phone?

    From David@wibble@btinternet.com to uk.telecom.mobile on Mon Aug 3 13:22:29 2026
    From Newsgroup: uk.telecom.mobile

    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.
    -u1.59 a month provides 100GB of storage which would just about do if I
    backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    If not, what strategy do you use?

    Cheers



    Dave R
    --
    AMD FX-6300 in GA-990X-Gaming SLI-CF running Windows 10 x64

    --
    This email has been checked for viruses by Avast antivirus software. www.avast.com
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Chris Green@cl@isbd.net to uk.telecom.mobile on Mon Aug 3 14:45:17 2026
    From Newsgroup: uk.telecom.mobile

    David <wibble@btinternet.com> wrote:
    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.
    -u1.59 a month provides 100GB of storage which would just about do if I backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    If not, what strategy do you use?

    I don't put anything worth backing up on my mobile phone! :-)

    More seriously I keep things like address book on my own storage and
    copy to desktop/laptop/phone as needed.

    If you have lots of images on your phone (likely given the amount of
    storage you're using) then find a way (an app maybe) of copying them
    to somewhere safe. A NAS storage system is a good investment and you
    don't pay monthly or rely on Google for your backups.

    Finally, try and keep a list of the apps you've added to your phone.
    Much of the storage used is probably apps and there's no point in
    backing them up, you can download and install them again. You just need
    some sort of record so you don't have to go through the pain of
    choosing which apps you need again.
    --
    Chris Green
    -+
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Andy Burns@usenet@andyburns.uk to uk.telecom.mobile on Mon Aug 3 14:55:59 2026
    From Newsgroup: uk.telecom.mobile

    David wrote:

    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.

    I get 15GB free (possibly due to having owned various Nexus/Pixel
    devices, or the length of time I've had the account?) and it regularly
    moans at me to tidy it up, which I do.

    -u1.59 a month provides 100GB of storage which would just about do if I backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    I don't pay for more space.

    If not, what strategy do you use?
    I let the phone backup its "data" contacts, photos, calendar, sms, call-history etc to google's cloud.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From David Wade@g4ugm@dave.invalid to uk.telecom.mobile on Mon Aug 3 15:00:22 2026
    From Newsgroup: uk.telecom.mobile

    On 03/08/2026 14:22, David wrote:
    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.
    -u1.59 a month provides 100GB of storage which would just about do if I backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    I pay monthly for storage for GMAIL


    If not, what strategy do you use?

    I don't back up my photos and videos to google. I back them up to
    onedrive because that gave me 1Tb of storage for around -u6.00/month so I could save PC info there as well. Its now around -u8.50 but I store lots
    of data there. And while you all rant "its not a backup", I also do
    local backups, my one drive data is synced to four PCs etc etc etc.


    Cheers



    Dave R


    Dave
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Java Jive@java@evij.com.invalid to uk.telecom.mobile on Mon Aug 3 15:19:43 2026
    From Newsgroup: uk.telecom.mobile

    On 2026-08-03 14:22, David wrote:
    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.
    -u1.59 a month provides 100GB of storage which would just about do if I backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    If not, what strategy do you use?
    I connect the phone to a PC and just copy all the contents visible
    thereby to a sub-directory on the PC, and from there it's backed up to
    my NAS.
    --

    Fake news kills!

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

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From David@wibble@btinternet.com to uk.telecom.mobile on Mon Aug 3 14:43:26 2026
    From Newsgroup: uk.telecom.mobile

    On Mon, 03 Aug 2026 14:45:17 +0100, Chris Green wrote:

    David <wibble@btinternet.com> wrote:
    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.
    -u1.59 a month provides 100GB of storage which would just about do if I
    backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    If not, what strategy do you use?

    <snip>

    Finally, try and keep a list of the apps you've added to your phone.
    Much of the storage used is probably apps and there's no point in
    backing them up, you can download and install them again. You just need
    some sort of record so you don't have to go through the pain of choosing which apps you need again.

    I have a large number of Apps on my phone, so I wouldn't want to spend a
    long time re-installing them all.
    There is also the data associated with the Apps.
    I am looking for a way of transferring the configuration to another phone,
    or restoring to the original in the event of a catastrophe of some sort.

    To my mind that is what backups are for.

    Cheers



    Dave R
    --
    AMD FX-6300 in GA-990X-Gaming SLI-CF running Windows 10 x64

    --
    This email has been checked for viruses by Avast antivirus software. www.avast.com
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Chris in Makati@mail@nospam.com to uk.telecom.mobile on Mon Aug 3 16:06:45 2026
    From Newsgroup: uk.telecom.mobile

    On Mon, 3 Aug 2026 14:45:17 +0100, Chris Green <cl@isbd.net> wrote:

    u1.59 a month provides 100GB of storage which would just about do if I
    backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?

    I pay u15.99 a year for 100 GB of storage on Google.

    About 19 GB of that is taken up by Gmail, and 6 GB by Google Drive. So
    I'm only using about 25% of my available storage.

    Chris
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Mon Aug 3 09:50:24 2026
    From Newsgroup: uk.telecom.mobile

    David wrote:
    Finally, try and keep a list of the apps you've added to your phone.
    Much of the storage used is probably apps and there's no point in
    backing them up, you can download and install them again. You just need
    some sort of record so you don't have to go through the pain of choosing
    which apps you need again.

    I have a large number of Apps on my phone, so I wouldn't want to spend a long time re-installing them all.
    There is also the data associated with the Apps.
    I am looking for a way of transferring the configuration to another phone, or restoring to the original in the event of a catastrophe of some sort.

    To my mind that is what backups are for.

    I'm not sure what this thread has to do with UK telecom, but in an exact mirror of this topic on the operating system newsgroups (win,linux,macos), we've been discussing the "perfect backup" solution for a few days now.

    Newsgroups: comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps
    Subject: PSA: Script to archive working APK & APK bundles from Android to
    the desktop
    Date: Sat, 1 Aug 2026 11:10:31 -0800
    Message-ID: <114lgb8$d6p$1@nnrp.usenet.blueworldhosting.com>

    Regarding archiving all apps and their data, we have to understand that
    almost everything people "think" about Apple/Google solutions, is wrong.

    Unless you know what you're doing (which one out of a million people do),
    you will *never* get the app backed up by either the Apple or Google highly marketed methods, simply because both get the app from their App Stores.
    a. So if the sub version you want isn't available, you lose
    b. Worse, if the app is no longer on the App Store, you lose

    There are ways on both platforms to back up and restore the *actual* app
    (which I've posted to the Apple & Android newsgroups in the past), but my
    main point is to ensure people know that the app is *never* backed up using the conventional methods that both Google and Apple marketing promote.

    Even the app data has quirks, e.g., Google limits app data to 25MB per app.

    Basically, while almost the whole world uses the marketing-driven
    Apple/Google backup/restore methods, they both suck for a bunch of reasons.

    As for what we've been discussing for a few days now on the OS newsgroups, IMHO, this is a much better backup/restore for Android apps and their data.
    <https://github.com/mrrfv/open-android-backup>

    Note it wasn't posted to the uk telecom group 'cuz it has nothing to do
    with a UK telecom topic, so it's here only because it's this thread topic.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Mon Aug 3 10:01:53 2026
    From Newsgroup: uk.telecom.mobile

    Andy Burns wrote:
    If not, what strategy do you use?
    I let the phone backup its "data" contacts, photos, calendar, sms, call-history etc to google's cloud.

    Hi Andy,

    This isn't UK telecom related, but how do you backup/restore your apps?
    And your app data?
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Mon Aug 3 10:39:01 2026
    From Newsgroup: uk.telecom.mobile

    Java Jive wrote:
    Does anyone pay monthly to Google for backup capability?

    If not, what strategy do you use?
    I connect the phone to a PC and just copy all the contents visible
    thereby to a sub-directory on the PC, and from there it's backed up to
    my NAS.

    I have plenty of iPads and Android tablets & phones, all of which need to
    be backed up and restored from time to time, so this question is apropos.

    Regarding the OP's question, the instant you pay for anything on a device,
    your privacy is toast, and, you're limited to what marketing decrees.

    Given neither the Google nor the Apple highly marketed backup/restore mechanisms actually back up and restore the actual app on your device,
    I looked up whether they can back up & restore at least the app data.

    Even if you're rooted on Android, the Google backup and restore
    mechanism(s) do NOT back up all your app data, for a variety of reasons,
    not the least of which is both methods (Android Backup Service & Google One Backup) can not access anything in /data/data, even if you're rooted.

    So what the Open Android Backup mechanism does that Google can't do is:
    a. Backup/restore every app
    (whether or not the app or version is on the App Store)
    b. Backup/restore *all* app data (but only if you're rooted and even if
    the developer opted out of backup/restore, which is common)
    c. For free, sans size limitations, and without ever using the Internet
    <https://github.com/mrrfv/open-android-backup>

    Apple's backup is maybe better than Google's but it still does NOT back up:
    a. the actual app binary (IPA)
    b. the exact version installed on your device
    c. all app data for all apps

    Just like Android, Apple has two backup mechanisms:
    1. iCloud Backup
    2. iTunes / Finder Backup

    In both google/apple cases
    a. The APK/IPA is never backed up (as it's installed from the App Store)
    b. So you lose both apps & data (if they're not on the App Store)
    c. The developers can opt out (and many do opt out of backing up data)

    But at least the iTunes method doesn't require the Internet and it can back
    up any size data that fits on your desktop.

    What's different about Open Android Backup is:
    A. It backs up the exact app binary (including the sub version)
    B. For any app installed on the device (not just those in the App Store)
    C. Backs up the full app data (if you're rooted) of any size
    D. Works offline (although iTunes also works offline)
    E. It bypasses developer opt out (which is surprisingly common)
    F. It is FOSS

    Given that, it's going to be my new backup/restore solution moving forward.
    At least for Android. I don't really have a good solution for iOS though.

    How about others?
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Andy Burns@usenet@andyburns.uk to uk.telecom.mobile on Mon Aug 3 19:59:16 2026
    From Newsgroup: uk.telecom.mobile

    Maria Sophia wrote:

    This isn't UK telecom related, but how do you backup/restore your apps?

    It's more that I let Play Store remember the list of apps I have
    installed ... when a screen went faulty on a phone and I swapped it
    in-store, it installed all the right apps

    And your app data?

    Again mostly through apps making use of Backup&Restore or BackupAgent
    onto to google cloud, I know a couple of my apps don't use that
    facility, so I have to manually export settings for them (Thunderbird
    being one, I don't need to export the actual emails as that's IMAP).
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From grinch@grinch@somewhere.net to uk.telecom.mobile on Tue Aug 4 11:11:20 2026
    From Newsgroup: uk.telecom.mobile

    On 03/08/2026 15:19, Java Jive wrote:
    On 2026-08-03 14:22, David wrote:
    Google(!) recommends that you back up your phone to the cloud.

    My phone has 256GB of internal storage plus a 256GB SD card.
    Internal storage has 102.5 GB used.
    External storage has 34.3 GB used.

    Google provides 5GB of storage free.
    -u1.59 a month provides 100GB of storage which would just about do if I
    backed up some data to the PC and deleted it from the phone.

    Does anyone pay monthly to Google for backup capability?


    Given that Uncle Sam has enacted a law which says that they must be
    allowed to see any data hosted by an American company no matter where in
    the word its hosted.

    Certainly not!!


    If not, what strategy do you use?

    I connect the phone to a PC and just copy all the contents visible
    thereby to a sub-directory on the PC, and from there it's backed up to
    my NAS.



    I do the same to my pair of NAS boxes and once a week backup to a 2TB
    USB disk which spends the rest of its life in a fireproof document box.

    As my entire life is not on my phone I only back it up monthly or when
    there is something important on it such as new photos etc.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Tue Aug 4 09:31:35 2026
    From Newsgroup: uk.telecom.mobile

    Andy Burns wrote:
    It's more that I let Play Store remember the list of apps I have
    installed ... when a screen went faulty on a phone and I swapped it in-store, it installed all the right apps.

    Thanks. I was wondering since I know you to be technical.

    Both Apple and Google are pretty good at migrating from one phone to
    another nowadays, where neither actually installs the APK on the device.

    Both install only from their respective App Stores, so, if the version on
    the old phone isn't the same as what's on the App Store, you don't get it.

    There are ways around this (even for Apple's iOS) but that's an aside.
    Did you get your original home screen back when it swapped the apps?

    And your app data?

    Again mostly through apps making use of Backup&Restore or BackupAgent
    onto to google cloud, I know a couple of my apps don't use that
    facility, so I have to manually export settings for them (Thunderbird
    being one, I don't need to export the actual emails as that's IMAP).

    Thanks. App data is the hardest thing, nowadays, to ensure gets recovered. Mainly due to modern restrictions on /data/data but also due to sheer size.

    Even the Google Play mechanisms won't allow more than 25MB per app.
    It's my understanding that they don't allow more than 50MB per phone.

    But I'm told the Google mechanism works well restoring app settings.
    But data is a different beast due to modern Android r/w restrictions.

    Nowadays, we basically have to be rooted to back up data reliably.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Andy Burns@usenet@andyburns.uk to uk.telecom.mobile on Tue Aug 4 18:50:32 2026
    From Newsgroup: uk.telecom.mobile

    Maria Sophia wrote:

    Did you get your original home screen back when it swapped the apps?

    I think I got an icon for every app installed ...

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Andy Burns@usenet@andyburns.uk to uk.telecom.mobile on Tue Aug 4 18:52:25 2026
    From Newsgroup: uk.telecom.mobile

    Maria Sophia wrote:

    Thanks. App data is the hardest thing, nowadays, to ensure gets recovered. Mainly due to modern restrictions on /data/data but also due to sheer size.

    Even the Google Play mechanisms won't allow more than 25MB per app.
    It's my understanding that they don't allow more than 50MB per phone.

    I knew it was 25MB per app, and that it doesn't count towards *my* cloud usage, wasn't aware of a 50MB per phone limit?

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Tue Aug 4 12:16:36 2026
    From Newsgroup: uk.telecom.mobile

    Andy Burns wrote:
    Did you get your original home screen back when it swapped the apps?

    I think I got an icon for every app installed ...

    Ah. My bad. I didn't ask clearly. Of course you got an icon for every app
    that was installed (well, almost every app as some don't have launchers).

    But was that icon in the exact same place on the new phone as on the old?

    There's a reason I'm asking this, since my upgrades have the old phone and
    the new phone with the app icons in exactly the same spot when I migrate.
    <https://i.postimg.cc/xTDmWpt4/organization-phone-pc.jpg>

    We invest a lot of time organizing both our PC's and phones, so my
    philosophy is that the entire organization moves with each migration.

    Each time I migrate to a new device (PC or phone), I copy the homescreen.
    <https://i.postimg.cc/Gmbyp807/windows-android.jpg>

    My desktop menus are from Windows XP days since what you do on a computer
    has never changed, just like what we do on a phone has never changed.

    For Windows10, your entire custom menu structure is just one folder.
    For Android, it's just one file.

    Even the Google Play mechanisms won't allow more than 25MB per app.
    It's my understanding that they don't allow more than 50MB per phone.

    I knew it was 25MB per app, and that it doesn't count towards *my* cloud usage, wasn't aware of a 50MB per phone limit?

    Ah. Thanks for keeping me honest. I looked it up. I can't find a reference.
    *Back up large amounts of data with the Android Large Backups API Program*
    <https://developer.android.com/identity/data/large-backups>

    *Back up user data with Auto Backup*
    <https://developer.android.com/identity/data/autobackup>

    So, you're right most likely.
    There's only the 25MB per app limit.
    The only quota is per-app, not per-device.

    Thank you for correcting my statement.
    I love when that's done 'cuz I learn more when that happens!

    Much appreciated!
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Chris Green@cl@isbd.net to uk.telecom.mobile on Wed Aug 5 09:02:27 2026
    From Newsgroup: uk.telecom.mobile

    Maria Sophia <mariasophia@comprehension.com> wrote:

    Again mostly through apps making use of Backup&Restore or BackupAgent
    onto to google cloud, I know a couple of my apps don't use that
    facility, so I have to manually export settings for them (Thunderbird being one, I don't need to export the actual emails as that's IMAP).

    Thanks. App data is the hardest thing, nowadays, to ensure gets recovered. Mainly due to modern restrictions on /data/data but also due to sheer size.

    It's a rather fundamental difficulty (or difference if you want)
    between the way user data and configuration is stored on different systems.

    On Andoid (and I guess IOS) app configuration and data is stored
    (mostly) by the app in its own private space, often not even directly accessible by the user. On Linux the user's configuration relating to
    programs and the user's data is stored in the user's home directory
    directly under the uer's control. MS Windows is somewhere in between
    the two.

    Thus, on Linux to make sure all my configuration and data is safe all
    I need to back up is my home directory (not quite true but it is how
    things are intended to be). In principle one can copy one's home
    directory to a new system and, if the same programs are installed,
    things will work as before.

    On Android however, since an app controls how and where its
    configuration and data are stored it's much more difficult (well nigh impossible) for the user to back things up independent of the app. You
    have to rely on the OS and/or the app to manage things for you.

    The Andoid security model depends quite a lot on each app being
    independent and not being able to access data from other apps. It's
    not a way that I personally like at all and thus I use Android as
    little as possible.
    --
    Chris Green
    -+
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From nospam@nospam@please.invalid (AnthonyL) to uk.telecom.mobile on Wed Aug 5 14:10:58 2026
    From Newsgroup: uk.telecom.mobile

    On Mon, 3 Aug 2026 09:50:24 -0800, Maria Sophia
    <mariasophia@comprehension.com> wrote:

    David wrote:
    Finally, try and keep a list of the apps you've added to your phone.
    Much of the storage used is probably apps and there's no point in
    backing them up, you can download and install them again. You just need
    some sort of record so you don't have to go through the pain of choosing >>> which apps you need again.

    I have a large number of Apps on my phone, so I wouldn't want to spend a
    long time re-installing them all.
    There is also the data associated with the Apps.
    I am looking for a way of transferring the configuration to another phone, >> or restoring to the original in the event of a catastrophe of some sort.

    To my mind that is what backups are for.

    I'm not sure what this thread has to do with UK telecom, but in an exact >mirror of this topic on the operating system newsgroups (win,linux,macos), >we've been discussing the "perfect backup" solution for a few days now.

    Newsgroups:
    comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps
    Subject: PSA: Script to archive working APK & APK bundles from Android to
    the desktop
    Date: Sat, 1 Aug 2026 11:10:31 -0800
    Message-ID: <114lgb8$d6p$1@nnrp.usenet.blueworldhosting.com>

    Regarding archiving all apps and their data, we have to understand that >almost everything people "think" about Apple/Google solutions, is wrong.

    Unless you know what you're doing (which one out of a million people do), >you will *never* get the app backed up by either the Apple or Google highly >marketed methods, simply because both get the app from their App Stores.
    a. So if the sub version you want isn't available, you lose
    b. Worse, if the app is no longer on the App Store, you lose

    There are ways on both platforms to back up and restore the *actual* app >(which I've posted to the Apple & Android newsgroups in the past), but my >main point is to ensure people know that the app is *never* backed up using >the conventional methods that both Google and Apple marketing promote.

    Even the app data has quirks, e.g., Google limits app data to 25MB per app.

    Basically, while almost the whole world uses the marketing-driven >Apple/Google backup/restore methods, they both suck for a bunch of reasons.

    As for what we've been discussing for a few days now on the OS newsgroups, >IMHO, this is a much better backup/restore for Android apps and their data.
    <https://github.com/mrrfv/open-android-backup>


    Interesting. Can it be used to setup a new Android phone? Or does it
    require the original phone?

    Does it recognise where the app came from eg FDroid, PlayStore etc?
    for when updates are needed if restoring/re-installing to a new phone?

    I've just setup a new phone and made a list of my apps with
    AppListBackup and then re-installed. Possibly no bad thing because
    the phone is a later version of Android and some better apps were then available.
    --
    AnthonyL

    Why ever wait to finish a job before starting the next?
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Andy Burns@usenet@andyburns.uk to uk.telecom.mobile on Wed Aug 5 16:58:10 2026
    From Newsgroup: uk.telecom.mobile

    Maria Sophia wrote:

    this is a much better backup/restore for Android apps and their data.
    <https://github.com/mrrfv/open-android-backup>

    Interesting ... surprised it doesn't need root on the phone?

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Wed Aug 5 12:15:50 2026
    From Newsgroup: uk.telecom.mobile

    Andy Burns wrote:
    this is a much better backup/restore for Android apps and their data.
    <https://github.com/mrrfv/open-android-backup>

    Interesting ... surprised it doesn't need root on the phone?

    Hi Andy,

    The FOSS open-android-backup x-platform tool does need root (for data).
    Nothing but root can bypass /data/data app-data sandboxing (AFAIK).

    Other than backing up APKs (which neither Google nor Apple backup does),
    this concept of backing up app data is confusing because Google keeps
    changing Android security & because apps can choose where to store data.

    Without root, even with Shizuku, Google backup or Swift or NeoBackup, etc. can't back up data that the app developer just doesn't want us to back up.

    Apps must explicitly enable android:allowBackup="true" and apps must store
    that data in a place that is accessible to the user (i.e., not /data/data).

    Apps that want their data backed up (e.g., contact apps) will allow export.
    Or they can store data in external storage /sdcard/Android/data/<package>.
    --
    BTW, further research shows Google's old Auto Backup has the 25MB limit
    but apparently the newer device backup mechanism has different limitations.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Wed Aug 5 13:27:21 2026
    From Newsgroup: uk.telecom.mobile

    AnthonyL wrote:
    IMHO, this is a much better backup/restore for Android apps and their data. >> <https://github.com/mrrfv/open-android-backup>


    Interesting. Can it be used to setup a new Android phone? Or does it
    require the original phone?

    Does it recognise where the app came from eg FDroid, PlayStore etc?
    for when updates are needed if restoring/re-installing to a new phone?

    I've just setup a new phone and made a list of my apps with
    AppListBackup and then re-installed. Possibly no bad thing because
    the phone is a later version of Android and some better apps were then available.

    Good questions! Good observations. You used a good process too.
    a. Enumerate all apps on the device
    b. Back them up from the old phone to the desktop
    c. Restore them to the new phone from the desktop

    To answer your question, yes, Open Android backup can be used to set up a
    new phone based on the apps that are on the old phone, and, if you copy
    over the homescreen (which is only a single file), you get the new apps in
    the exact same placement on the new phone as they were on the old phone.

    With respect to the query of where apps came from (e.g., F-Droid, Github,
    Play Store, developer web site, etc.) Open Android Backup doesn't care 'cuz Android is unique among operating systems in how it saves installers.

    To understand why Open Android Backup doesn't need to care where an app
    came from, think about a situation which is becoming common on desktops.

    On Windows, there are some "portable apps" which themselves, are the actual executable (as opposed to being an installer which creates the executable).

    Right?

    Well, on Android, every app (even system apps!) is a portable executable.
    So all Open Android Backup needs to do is collect all those executables.

    If an app is installed on the phone, then the installer is *always* there!

    So, Open Android Backup doesn't care where the original APK came from.
    If they're on the phone, they're backed up. And they can be re-installed.

    Here's a short list of what Open Android Backup backs up sans root:
    a. Photos, Videos, Documents, Downloads, etc.
    b. App-created files stored in or exported to /sdcard
    c. Accessible app data such as contacts & chats (if exported to /sdcard)
    d. Backs up SMS/Call logs (for viewing, not for restoring)

    Note that root doesn't gain Open Android Backup anything special.
    Just like root doesn't gain a Google Backup anything special.

    But root gains NeoBackup or Swift Backup a lot.
    a. Root gains cloning of the app on the new phone, and,
    b. Root gains all the app data backed up to the new phone.
    c. And root gains the same app system state on the new phone.
    Hardware limits accepted.

    When we compare an unrooted backup above with Google Backup, the methods
    are completely different (e.g., Google never backs up the APKs), but Google Backup does bring over stuff like contacts, SMS, call logs, wi-fi
    passwords, bluetooth pairings, launcher layout, Google & Samsung accounts,
    app permissions & notification settings, system settings, etc.

    So all three methods are fundamentally different in critical ways.
    A. Open Android Backup is really about archiving apps to the desktop
    B. Swift/NeoBackup are really about full backup/restore when rooted
    C. Google Backup is really more about bringing over the same setup

    As always, anything I say can be wrong (and probably is), so please
    fix where I err or omit so that we end up with more knowledge overall.
    --
    Usenet allows purposefully helpful people to pool their experiences.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Wed Aug 5 13:31:56 2026
    From Newsgroup: uk.telecom.mobile

    Maria Sophia wrote:
    this is a much better backup/restore for Android apps and their data.
    <https://github.com/mrrfv/open-android-backup>

    Interesting ... surprised it doesn't need root on the phone?

    Hi Andy,

    The FOSS open-android-backup x-platform tool does need root (for data). Nothing but root can bypass /data/data app-data sandboxing (AFAIK).

    Actually, I looked deeper. I don't see any overt evidence that root will
    change how either Open Android Backup or the Google Backup mechanisms work.

    Root really matters mainly for the full-backup solutions that NeoBackup or SwiftBackup perform, and not so much for OAB or for Google Backup methods.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From David@wibble@btinternet.com to uk.telecom.mobile on Fri Aug 7 11:17:13 2026
    From Newsgroup: uk.telecom.mobile

    On Wed, 05 Aug 2026 13:31:56 -0800, Maria Sophia wrote:

    Maria Sophia wrote:
    this is a much better backup/restore for Android apps and their data.
    <https://github.com/mrrfv/open-android-backup>

    Interesting ... surprised it doesn't need root on the phone?

    Hi Andy,

    The FOSS open-android-backup x-platform tool does need root (for data).
    Nothing but root can bypass /data/data app-data sandboxing (AFAIK).

    Actually, I looked deeper. I don't see any overt evidence that root will change how either Open Android Backup or the Google Backup mechanisms
    work.

    Root really matters mainly for the full-backup solutions that NeoBackup
    or SwiftBackup perform, and not so much for OAB or for Google Backup
    methods.

    Thanks to all for the helpful information.

    One further thought: UK mobile phone shops will transfer stuff from your
    old to new phone if you buy from them.
    Does anyone know what software they use?

    Cheers



    Dave R
    --
    AMD FX-6300 in GA-990X-Gaming SLI-CF running Windows 10 x64

    --
    This email has been checked for viruses by Avast antivirus software. www.avast.com
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From nospam@nospam@please.invalid (AnthonyL) to uk.telecom.mobile on Fri Aug 7 11:30:05 2026
    From Newsgroup: uk.telecom.mobile

    On Wed, 5 Aug 2026 13:27:21 -0800, Maria Sophia
    <mariasophia@comprehension.com> wrote:

    AnthonyL wrote:
    IMHO, this is a much better backup/restore for Android apps and their data. >>> <https://github.com/mrrfv/open-android-backup>


    Interesting. Can it be used to setup a new Android phone? Or does it
    require the original phone?

    Does it recognise where the app came from eg FDroid, PlayStore etc?
    for when updates are needed if restoring/re-installing to a new phone?

    I've just setup a new phone and made a list of my apps with
    AppListBackup and then re-installed. Possibly no bad thing because
    the phone is a later version of Android and some better apps were then
    available.

    Good questions! Good observations. You used a good process too.
    a. Enumerate all apps on the device
    b. Back them up from the old phone to the desktop
    c. Restore them to the new phone from the desktop

    To answer your question, yes, Open Android backup can be used to set up a
    new phone based on the apps that are on the old phone, and, if you copy
    over the homescreen (which is only a single file), you get the new apps in >the exact same placement on the new phone as they were on the old phone.

    With respect to the query of where apps came from (e.g., F-Droid, Github, >Play Store, developer web site, etc.) Open Android Backup doesn't care 'cuz >Android is unique among operating systems in how it saves installers.

    To understand why Open Android Backup doesn't need to care where an app
    came from, think about a situation which is becoming common on desktops.

    On Windows, there are some "portable apps" which themselves, are the actual >executable (as opposed to being an installer which creates the executable).

    Right?

    Well, on Android, every app (even system apps!) is a portable executable.
    So all Open Android Backup needs to do is collect all those executables.

    If an app is installed on the phone, then the installer is *always* there!

    So, Open Android Backup doesn't care where the original APK came from.
    If they're on the phone, they're backed up. And they can be re-installed.

    Here's a short list of what Open Android Backup backs up sans root:
    a. Photos, Videos, Documents, Downloads, etc.
    b. App-created files stored in or exported to /sdcard
    c. Accessible app data such as contacts & chats (if exported to /sdcard)
    d. Backs up SMS/Call logs (for viewing, not for restoring)

    Note that root doesn't gain Open Android Backup anything special.
    Just like root doesn't gain a Google Backup anything special.

    But root gains NeoBackup or Swift Backup a lot.
    a. Root gains cloning of the app on the new phone, and,
    b. Root gains all the app data backed up to the new phone.
    c. And root gains the same app system state on the new phone.
    Hardware limits accepted.

    When we compare an unrooted backup above with Google Backup, the methods
    are completely different (e.g., Google never backs up the APKs), but Google >Backup does bring over stuff like contacts, SMS, call logs, wi-fi
    passwords, bluetooth pairings, launcher layout, Google & Samsung accounts, >app permissions & notification settings, system settings, etc.

    So all three methods are fundamentally different in critical ways.
    A. Open Android Backup is really about archiving apps to the desktop
    B. Swift/NeoBackup are really about full backup/restore when rooted
    C. Google Backup is really more about bringing over the same setup

    As always, anything I say can be wrong (and probably is), so please
    fix where I err or omit so that we end up with more knowledge overall.


    Very useful information.

    I might just try restoring a not too old phone to an older (but not
    too old) redundant phone. No doubt some apps won't run but it'll be a
    very handy learning process if ever I need to do it again. Bearing in
    mind I'm entering my 80th year and have just replaced my 8yr old phone
    so I met get away with not having to bother.
    --
    AnthonyL

    Why ever wait to finish a job before starting the next?
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Fri Aug 7 07:33:45 2026
    From Newsgroup: uk.telecom.mobile

    AnthonyL wrote:
    Very useful information.

    I might just try restoring a not too old phone to an older (but not
    too old) redundant phone. No doubt some apps won't run but it'll be a
    very handy learning process if ever I need to do it again. Bearing in
    mind I'm entering my 80th year and have just replaced my 8yr old phone
    so I met get away with not having to bother.

    Hi AnthonyL,

    It's a worthy endeavor to restore one phone to another, especially since, nowadays, the entire homescreen can port over (as it's just a single file).

    So you get the same homescreen(s), and the same folders, and the same app icons, with the same names in the same positions on every device ported to.

    If the APK isn't installed yet, it shows up in gray, but when you tap it,
    the icon is programmed to go to the Google Play Store to get the app.

    However, if you want a different version, all you have to do is install the desired version from your APK archive, and the icon comes alive instantly.

    It used to be that the FOSS screen-copy app would install just by sliding.
    <https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg>
    But that stopped working with split APKs, but still it's easy to copy over.

    The homescreen is a single file (mine is 6MB in size) so it's portable.
    You end up with the same app icons in the same place on every phone.

    I find the only icons that don't port over consistently are just some of
    the dozens of single-tap shortcuts that I create using Muntashirakon AM.
    <https://muntashir.dev/AppManager/en/>

    Generally, what I create shortcuts to are deeply embedded settings, many of which are related to privacy, so Google & other apps hide them on purpose.

    Others are related to wi-fi, e.g., I have a 1-tap shortcut for APs that I commonly access (as I set MAC randomization & IP settings differently).

    Regarding your astute observation of "No doubt some apps won't run", most
    apps are pretty portable in my humble opinion, but I've mostly only tested phone-to-phone ARMv8-to-ARMv8 APK transfers using the APK and split APKs.

    Having cut my teeth on computers in the punched card days, I've lived
    through many backup/restore scenarios, where the one universal truth that
    you back up the installer at the time you install the program isn't really needed for Android, since Android never deletes the installer anyway.

    However, there are still good reasons to back up all your installed apps.
    1. If you ever delete the app, you will have a ready backup to restore
    2. If you like the current sub version, you will have a ready backup
    3. When you port from one phone to another, you have a complete archive

    Just as I back up all my installers on Windows at the time I install the program, I back up all my APKs at the time I install the apps on Android.
    [I would do it for iOS, but, Apple makes IPA backup rather difficult.]

    For Android APK backup/restore, I'd suggest either Muntashirakon or SAI.
    <https://github.com/MuntashirAkon/AppManager>
    <https://github.com/Aefyr/SAI>
    <https://f-droid.org/packages/com.aefyr.sai.fdroid/>
    Note the "SAI" on the Google Play store is an imposter.

    We're both around the same age, where I'm a tad bit older than you are. :)
    So you likely also experienced the entire realm of the personal computer.
    --
    In computers, a good philosophy is just as important as good technology.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Fri Aug 14 08:09:17 2026
    From Newsgroup: uk.telecom.mobile

    David wrote:
    Root really matters mainly for the full-backup solutions that NeoBackup
    or SwiftBackup perform, and not so much for OAB or for Google Backup
    methods.

    Thanks to all for the helpful information.

    You're welcome.

    The whole point of Usenet is to pool our combined experiences & efforts.

    Since this thread should help everyone back up their "real" APKs, namely:
    a. The EXACT APKs that are *installed* (exact sub versions)
    b. Whether or not that version (or even that app) is still in Google Play
    c. From a phone to a desktop (e.g., a Windows script is provided below)
    ... the first thing I need to reiterate is the APK is always there.

    Yes. Always.
    Only Android treats every installer as the installed 'executable'.

    So, the APK is *always* on your device if the app itself is on your device. Since that's the case, the script below should work for all Windows owners.

    :: -------------------------------------------------------------------
    :: copyapk.bat
    :: Pulls APKs already saved onto the phone to the Windows desktop.
    :: a. To an archival location on the desktop PC...
    :: b. over Wi-Fi or USB...
    :: c. without needing the Internet...
    :: -------------------------------------------------------------------
    :: v1p5 20260731 Improved comments for re-use by others on all desktops.
    :: v1p4 20260730 Added instructions for saving APK and split APKs files
    :: v1p3 20260730 Added a clean quit instead of typing control+C
    :: v1p2 20260730 Added choice of opening Muntashirakon App Manager
    :: v1p1 20260730 Added choice of destination directory
    :: v1p0 20260730 Original version (for use with Muntashirakon Save APK)
    :: -------------------------------------------------------------------
    :: Works on all Android phones precicesly because it copies...
    :: a. The EXACT APKs thqt are *installed* (i.e., the exact sub versions)
    :: b. Whether or not that version (or even that app) is still on Google Play
    :: c. From an Android to a desktop (i.e., to any storage on the LAN)
    :: Note: Android is unique in that *every* app saves the installer!
    :: -------------------------------------------------------------------
    :: WIP: Replace Windows commands with pure adb, which can do everything.
    :: That makes porting to macOS/Linux even more trivial to do.
    :: i. adb shell pm list packages
    :: ii. adb shell pm path <package>
    :: iii. adb pull <path-to-package>
    :: -------------------------------------------------------------------
    :: Workflow is
    :: On the phone, use any good FOSS archiver to save the current APKs
    :: a. This script can open the FOSS Muntashirakon App Manager archiver
    :: b. But it could just as easily open the FOSS SAI archiver
    :: c. Or any desired FOSS APK archiver
    :: Then run this script to copy that backed up package to PC storage
    :: -------------------------------------------------------------------
    :: Separately, backup/restore the complete Android homescreen setup.
    :: Then tapping on the grayed-out icons instantly installs the apps.
    :: -------------------------------------------------------------------
    :: The interface will ask if you want to back up apps right now.
    :: And it will ask where you want the apps copied to the desktop.
    :: Then it will ask which backed up apps to copy to the desktop.
    :: -------------------------------------------------------------------
    :: Setup assumes adb is connected to the phone (either Wi-Fi or USB)
    :: 1. Install desired apps on your Android phone by any method
    :: (Google Play, Aurora, F-droid, Github, archived APKs, whatever)
    :: 2. Install the FOSS Muntashirakon App Manager (best app on Android)
    :: <https://muntashir.dev/AppManager/en/> (doc)
    :: <https://github.com/MuntashirAkon/AppManager> (apk)
    :: 3. At any time, in App Manager, select app(s) and press "Save APK"
    :: That will save the APK or APKs bundle to a known static folder
    :: Example (note the apks is a modern Google Play zipped split bundle):
    :: /storage/emulated/0/AppManager/apks/Aurora Store_4.8.1.apk
    :: /storage/emulated/0/AppManager/apks/Caffeine_2.0.9.apks
    :: 4. Then run this script (which copies those installers to a desktop)
    :: The script optionally opens App Manager to the desired page
    :: 5. Optionally, use a launcher which saves the homescreen to a file
    :: For example, Nova Launcher backs up and restores all homescreens
    :: Last known good version of Nova Launcher 7.0.57 by TeslaCoil
    :: <https://tinyurl.com/nova-launcher>
    :: <https://mobile.softpedia.com/apk/nova-launcher/7.0.57/>
    :: <https://filehippo.com/android/download_nova-launcher/7.0.57/>
    ;: But any launcher that can backup/restore the homescreen is fine
    :: 6. With the homescreen and apps backed up, reinstallation is simple
    :: a. Restore the single ~5MB homescreen backup file on any Android
    :: b. Tap, in place, the grayed-out icons to re-install the apps
    :: c. The grayed out icons will immediately search Google Play
    :: for the latest version, or you can choose your backup version
    :: -------------------------------------------------------------------
    @echo off
    setlocal enabledelayedexpansion

    REM ===== Ask user if they want to open Muntashirakon App Manager =====
    echo.
    echo Do you want to open Muntashirakon App Manager before listing APKs?
    echo Once open, select apps and tap the "Save APK" option.
    echo Either an APK or an APKs bundle will be saved to
    echo /storage/emulated/0/AppManager/apks/{file.apk,file.apks}
    set /p openAM="Open App Manager? (Y/N): "

    if /i "%openAM%"=="Y" (
    echo Launching App Manager...
    REM Try clean launch first
    adb shell am start io.github.muntashirakon.AppManager/.main.MainActivity >nul 2>&1

    REM If that fails, use monkey silently
    adb shell monkey -p io.github.muntashirakon.AppManager 1 >nul 2>&1

    echo App Manager launched. Press ENTER when ready to continue.
    pause
    )

    REM ===== Default destination folder [set for each desktop] =====
    set "DEST=H:\20230620_failing_disc\bck\==========\phone\apk\apk_from_muntashirakon"

    echo.
    echo Default destination is:
    echo %DEST%
    echo.

    set /p changeDest="Press ENTER to accept, or type a new destination: "

    if not "%changeDest%"=="" (
    set "DEST=%changeDest%"
    )

    echo.
    echo Using destination:
    echo %DEST%
    echo.

    REM Create destination folder if missing
    if not exist "%DEST%" (
    echo Creating folder: %DEST%
    mkdir "%DEST%"
    )

    echo.
    echo Listing APK/APKS files on device...
    echo.

    REM Get file list from device
    adb shell ls "/storage/emulated/0/AppManager/apks" > filelist.txt

    set /a count=0

    REM Display numbered list
    for /f "delims=" %%A in (filelist.txt) do (
    set /a count+=1
    set "file!count!=%%A"
    echo !count!: %%A
    )

    if %count%==0 (
    echo No APKs found in /storage/emulated/0/AppManager/apks
    del filelist.txt
    exit /b
    )

    echo.
    echo Enter numbers to pull (example: 1 3 5), type ALL, or type Q to quit:
    set /p selection="Selection: "

    if /i "%selection%"=="Q" (
    echo Exiting...
    del filelist.txt
    endlocal
    exit /b
    )

    echo.

    if /i "%selection%"=="ALL" (
    echo Pulling ALL files...
    for /l %%i in (1,1,%count%) do (
    echo Pulling !file%%i! ...
    adb pull "/storage/emulated/0/AppManager/apks/!file%%i!" "%DEST%"
    )
    goto done
    )

    REM Pull selected numbers
    for %%i in (%selection%) do (
    if %%i LEQ %count% (
    echo Pulling !file%%i! ...
    adb pull "/storage/emulated/0/AppManager/apks/!file%%i!" "%DEST%"
    ) else (
    echo Invalid selection: %%i
    )
    )

    :done
    echo.
    echo Done.
    del filelist.txt
    endlocal

    :: end of copyapk.bat
    --
    Posted out of the goodness of my heart to help others do what I do.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to uk.telecom.mobile on Fri Aug 14 08:20:48 2026
    From Newsgroup: uk.telecom.mobile

    Andy Burns wrote:
    Maria Sophia wrote:

    Thanks. App data is the hardest thing, nowadays, to ensure gets recovered. >> Mainly due to modern restrictions on /data/data but also due to sheer size. >>
    Even the Google Play mechanisms won't allow more than 25MB per app.
    It's my understanding that they don't allow more than 50MB per phone.

    I knew it was 25MB per app, and that it doesn't count towards *my* cloud usage, wasn't aware of a 50MB per phone limit?

    Hi Andy,

    I was mistaken about the 50MB per phone limit. Mea culpa. I apologize.
    The 25MB/app limit is there (AFAIK), so we're both on the same page now.

    Speaking of being on hte same page, I know you're on the Windows ngs,
    so you're likely aware of the adb connection scripts, but most of the
    folks here might not realize it's trivial to connect the phone to the
    PC & operate the phone on the PC without needing accounts or the net.

    To that end, I'll append the three adb-connection-debug-and-test scripts.

    The purpose is so that everyone benefits on every platform, since all
    these scripts can work on Windows/Linux/macOS, but I only tested on
    Windows 10.

    :: --------------------------------------------------------------------
    :: adbconnect.bat
    :: Automate Android-to-desktop Wi-Fi adb and scrcpy (mirroring)
    :: a. ADB provides complete control of the phone from the desktop
    :: b. Over USB or Wi-Fi (I exclusively used Wi-Fi in all my testing)
    :: c. Mirroring the phone (scrcpy) so that the desktop controls it
    :: i. The desktop monitor displays the phone
    :: ii. The desktop speakers output the phone audio
    :: iii. The desktop keyboard types into the phone's keyboard input
    :: iv. The desktop mouse taps on the mirror to operate the phone
    :: v. The desktop clipboard works seamlessly with the phone keyboard
    :: vi. The desktop screen copying and editing tools work perfectly
    :: vii. All sans any need for the net or a privacy-robbing account
    :: --------------------------------------------------------------------
    :: v2p8 20260809
    :: Improved comments for general use by others on any desktop platform
    ::
    :: v2p7 20260807
    :: Added a disconnect for the old debug port right after
    :: adb connect %PHONE_IP%:5555, using the DEBUG_PORT captured
    ::
    :: v2p6 20260730
    :: Added detailed overview in the comments section for easy re-use
    ::
    :: v2p5 20260630
    :: Cleaned up the descriptions by summarizing the version comments.
    ::
    :: v2p4 20260630
    :: Added version output string and improved explanations
    ::
    :: v2p3 20260624
    :: Added ability to detect if USB authentication was already done
    ::
    :: v2p2 20260622
    :: Improved handling of offline and unauthorized states
    ::
    :: v2p1 20260621
    :: Added SUMMARY system for executed commands
    ::
    :: v2p0 20260621
    :: Restored working version from v1p7
    ::
    :: v1p9 20260620
    :: Removed debug-port connect step which broke Wireless Debugging
    ::
    :: v1p8 20260619
    :: Removed debug-port connect step which broke Wireless Debugging
    ::
    :: v1p7 20260615
    :: Removed requirement for scrcpy-noconsole.vbs
    ::
    :: v1p6 20260614
    :: Added VBS no-console launcher fallback
    ::
    :: v1p5 20260613
    :: Added query asking for phone LAN IP address
    ::
    :: v1p4 20260612
    :: Eliminated need for scrcpy console window (using no-console vbs)
    ::
    :: v1p3 20260612
    :: Improved reliability of adb devices parsing
    ::
    :: v1p2 20260611
    :: Added retry logic and improved device-id handling
    ::
    :: v1p1 20260611
    :: Improved device lookup and reliability
    ::
    :: v1p0 20260611
    :: Converted adbconnect.vbs from Genymotion scrcpy to adbconnect.bat
    :: Mirrors phone onto desktop over Wi-Fi (or USB) using adb and scrcpy
    :: --------------------------------------------------------------------
    :: Connects Android 11 and Android 12+ devices to adb and scrcpy using
    :: pairing mode and classic TCPIP mode. This script uses the Android
    :: Wireless Debugging pairing workflow to obtain the pairing port,
    :: pairing code and debug port from the phone. It then performs adb
    :: pair and adb connect with retry logic, switches the device to TCPIP
    :: port 5555 and launches scrcpy silently. This script does not use TLS
    :: for the scrcpy connection, but it depends on Wireless Debugging
    :: being active because Wireless Debugging controls whether adbd is
    :: reachable. Once TCPIP mode is enabled, the script reconnects to
    :: port 5555 and starts scrcpy over classic TCPIP mode.
    ::
    :: 1. Eliminates the useless scrcpy console window which takes up space
    :: 2. Eliminates random security steps in Wi-Fi adb connections
    :: 3. Solves reconnection problems when
    :: a. The phone leaves the LAN and returns
    :: b. The PC is rebooted
    :: c. The phone is rebooted
    :: d. A connection is attempted when already connected
    :: Uses Wireless Debugging mode plus classic TCPIP ADB mode.
    :: Wireless Debugging does not open port 5555 by itself.
    :: Classic ADB-over-WiFi can use port 5555 to simplify reconnects.
    :: Running adb tcpip 5555 forces Android to open port 5555 even in
    :: Wireless Debugging mode. This makes reconnections simpler because
    :: the phone stays open on port 5555 even if
    :: a. the phone leaves and rejoins the LAN
    :: b. the PC reboots
    :: c. scrcpy drops and reconnects
    :: Port 5555 remains active until the phone reboots because Android
    :: rebooting disables Wireless Debugging and closes the TCPIP daemon.
    ::
    :: USB authorization can eliminate pairing codes
    :: i. Connect via USB
    :: ii. adb connect PHONE_IP:5555
    :: iii. scrcpy --tcpip=PHONE_IP
    ::
    :: If a USB device is present and authorized, adb devices will show
    :: PHONE_IP:5555 device
    :: You cannot get device state without USB authorization
    ::
    :: Android 12+ introduced ADB-over-TLS auto-advertised via mDNS.
    :: It auto-connects over encrypted channels without pairing or ports.
    :: It appears as adb-SERIAL-GUID._adb-tls-connect._tcp
    :: Wireless Debugging controls whether this TLS service is awake.
    :: scrcpy cannot use the TLS auto-connect device directly.
    ::
    :: This script uses pairing mode and TCPIP mode only.
    :: TLS auto-connect is not used for scrcpy, but TLS must be awake
    :: for adbd to be reachable.
    ::
    :: This design removes all typical friction points:
    :: a. No USB cable
    :: b. No scrcpy console window
    :: c. No repeated pairing
    :: d. No manual port switching
    :: e. No manual IP entry (if static)
    :: f. No TLS scrcpy complications
    :: g. No adb-offline / unauthorized headaches
    ::
    :: There's the following in the script below:
    :: A. Reliable adb discovery
    :: a. finding adb across $PATH
    :: b. And forcing the exe to ensure reliability
    :: B. Reliable device-state detection
    :: a. Handling pairing failures
    :: b. retry timing
    :: c. debug-port connection
    :: d. fallback device-ID detection
    :: C. TCPIP mode forcing
    :: a. Which exploits adb tcpip 5555 classic TCPIP mode
    :: b. Such that the port stays open until the phone reboots
    :: c. Which is the key to making reconnection trivial.
    :: D. Silent scrcpy launch
    :: a. exploiting vbs capabilities
    :: b. For a no-console hassle-free experience
    :: E. Summary logging
    :: a. By appending only successful commands
    :: b. Which is useful for debugging intermittent Wireless Debugging behavior
    :: F. LAN-wide complete control
    :: a. Becuse it uses a static IP
    :: b. and a forced TCPIP mode with scrcpy over 5555
    :: c. We can operate the phone even if:
    :: i. it's asleep
    :: ii. it's locked
    :: iii. it's physically inaccessible
    :: G. Automatic recovery
    :: a. The script handles the phone leaving/rejoining LAN
    :: b. and/or a PC reboot
    :: c. and/or a phone reboot
    :: d. and/or a scrcpy reconnect
    :: e. and various adb offline states
    ::
    :: This is extremely powerful, as, for example, if you're at your desktop
    :: and you need to text someone from a phone on the LAN, it's easy to do.
    ::
    :: Of course there's always more to add, such as:
    :: 1. adding auto-IP discovery via ARP scan
    :: 2. adding auto-TLS detection for Android 12+
    :: 3. adding an auto-reconnect daemon
    :: 4. adding scrcpy overlay controls
    :: 5. adding phone battery/temperature polling
    :: 6. adding multi-device support
    :: 7. adding LAN broadcast discovery
    :: --------------------------------------------------------------------
    :: To integrate this script into a Windows quick-reaction command...
    :: 1. Test that your command is not yet known to Windows' special paths.
    :: Win+R > mirror
    :: You should see "Windows cannot find mirror..."
    :: NB: I don't use Win+R because I have a runbox pinned to the taskbar.
    ::
    :: 2. Create a shortcut that calls the batch file that does all the work.
    :: C:\path-to\lnk\mirror.lnk
    :: target=%comspec% /k cd C:\path-to\bat & C:\path-to\bat\adbconnect.bat
    ::
    :: 3. Add a registry key, making sure to name the key with an 'exe' extension.
    :: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\mirror.exe
    :: Default=C:\path-to\lnk\mirror.lnk
    :: NB : The destination must exist for this quick reaction key to work.
    ::
    :: 4. Test that your quick-reaction command is working to mirror Android.
    :: Win+R > mirror
    ::
    :: What should happen is:
    :: a. The runbox command finds "mirror.exe" in the App Paths key
    :: b. Which finds mirror.lnk in your shortcuts folder
    :: c. Which runs adbconnect.bat in your batch folder
    ::
    :: Note that this design makes use of App Paths as an instant global command
    :: a. App Paths works with shortcuts, not just executables
    :: b. It works with Win+R, Start menu search, and Explorer
    :: c. It allows naming the command anything (mirror.exe -> adbconnect.bat)
    :: d. It avoids $PATH pollution
    :: e. It eliminates %PATH duplication mistakes
    :: --------------------------------------------------------------------

    @echo off
    :: vi. debugging can be removed later
    :: echo MARK 1
    setlocal enabledelayedexpansion

    :: Version string
    set SCRIPT_VERSION=v2p5
    set SCRIPT_DATE=20260630

    echo ============================================
    echo ADB-over-TLS to TCPIP Launcher Debug Mode
    echo Running adbconnect.bat %SCRIPT_VERSION% %SCRIPT_DATE%
    echo ============================================
    echo.

    :: initialize temp summary file
    set SUMMARY_FILE=%TEMP%\adbconnect_summary.txt
    if exist "%SUMMARY_FILE%" del "%SUMMARY_FILE%"

    :: On phones with static IP addresses, change the next line
    set PHONE_IP=192.168.1.4
    :: set SCRCPY_OPTS=--keyboard=sdk --always-on-top
    set SCRCPY_OPTS=--keyboard=sdk

    echo.
    echo === ADB Wireless Auto-Connect ===
    echo === [Developer options > Wireless debugging > on] ===
    echo.

    REM 1. Find adb
    :: REM ii. debugging (can be removed later)
    :: if defined TRACE echo BEFORE FIRST FOR

    :: REM vii. debugging can be removed later
    :: echo MARK 2
    for /f "delims=" %%A in ('where adb 2^>nul') do (
    if not defined ADB set ADB=%%A
    )

    :: REM viii. debugging can be removed later
    :: echo MARK 3

    :: REM iii. debugging (can be removed later)
    :: if defined TRACE echo AFTER FIRST FOR


    if not defined ADB (
    echo [ERROR] adb.exe not found.
    exit /b
    )

    REM Ensure .exe extension
    if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

    echo Using ADB: "%ADB%"
    echo.

    REM 2. Check if already connected
    echo Checking existing ADB devices...

    :: REM i. debugging (can be removed later)
    :: set TRACE=1

    set DEVICE_ID=
    set DEVICE_STATE=

    REM Do not add extra quotes here as all these break batch parsing!
    :: '"%ADB%" devices'
    :: "%ADB%" devices
    :: '"%ADB%" devices"'
    :: '"%ADB%" devices"'

    :: REM iv. debugging can be removed later
    :: if defined TRACE echo BEFORE SECOND FOR

    :: REM ix. debugging can be removed later
    :: echo MARK 4
    for /f "skip=1 tokens=1,2" %%I in ('%ADB% devices') do (
    echo %%I | findstr /I "%PHONE_IP%" >nul && (
    if not defined DEVICE_ID (
    set DEVICE_ID=%%I
    set DEVICE_STATE=%%J
    )
    )
    )

    :: REM x. debugging can be removed later
    :: echo MARK 5

    :: REM v. debugging can be removed later
    :: if defined TRACE echo AFTER SECOND FOR

    REM treat only "device" as connected

    :: echo MARK 6
    echo DEVICE_ID="%DEVICE_ID%" DEVICE_STATE="%DEVICE_STATE%"

    REM if no device id, skip to NOT_CONNECTED
    if "%DEVICE_ID%"=="" goto NOT_CONNECTED

    REM if state is not "device", skip to NOT_CONNECTED
    if /I not "%DEVICE_STATE%"=="device" goto NOT_CONNECTED

    echo Already connected on %DEVICE_ID%
    echo adb devices>>"%SUMMARY_FILE%"

    REM skip redundant tcpip if already on 5555
    if /I "%DEVICE_ID:~-5%"==":5555" (
    echo Device already on port 5555. Skipping tcpip switch.
    goto RUN_SCRCPY
    )

    goto RUN_TCPIP

    :NOT_CONNECTED
    :: echo MARK 8
    echo Not connected. Need to pair.
    echo.

    REM 3. Ask user for pairing info
    echo Necessary pairing information will be shown on the phone:
    set /p PHONE_IP=Phone IP [%PHONE_IP%] :
    set /p PAIR_PORT=Wireless debugging pairing port:
    set /p PAIR_CODE=Wireless debugging pairing code:
    set /p DEBUG_PORT=Wireless debugging debug port:

    echo.
    echo Pairing with: %PHONE_IP%:%PAIR_PORT%

    REM Retry logic for adb pair (3 attempts)
    set ATTEMPTS_PAIR=0
    :PAIR_RETRY
    set /a ATTEMPTS_PAIR+=1
    "%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%

    if not errorlevel 1 (
    echo adb pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%>>"%SUMMARY_FILE%"
    )

    if errorlevel 1 (
    if !ATTEMPTS_PAIR! lss 3 (
    echo Pair failed, retrying...
    timeout /t 2 >nul
    goto PAIR_RETRY
    ) else (
    echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
    exit /b 1
    )
    )
    echo.

    echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%

    REM Retry logic for adb connect (3 attempts)
    set ATTEMPTS_CONN=0
    :CONNECT_RETRY
    set /a ATTEMPTS_CONN+=1
    "%ADB%" connect %PHONE_IP%:%DEBUG_PORT%

    if not errorlevel 1 (
    echo adb connect %PHONE_IP%:%DEBUG_PORT%>>"%SUMMARY_FILE%"
    )

    REM wait a few seconds for the Android adb daemon to be ready
    timeout /t 2 >nul

    if errorlevel 1 (
    if !ATTEMPTS_CONN! lss 3 (
    echo Connect failed, retrying...
    timeout /t 2 >nul
    goto CONNECT_RETRY
    ) else (
    echo [ERROR] adb connect %PHONE_IP%:%DEBUG_PORT% failed after %ATTEMPTS_CONN% attempts.
    exit /b 2
    )
    )
    echo.

    REM Do not add extra quotes here as all these break batch parsing!
    :: '"%ADB%" devices'
    :: "%ADB%" devices
    :: '"%ADB%" devices"'
    :: '"%ADB%" devices"'

    REM After connect, get the actual device id
    set DEVICE_ID=
    for /f "tokens=1" %%I in ('%ADB% devices ^| findstr /C:"%PHONE_IP%:"') do (
    if not defined DEVICE_ID set DEVICE_ID=%%I
    )

    if defined DEVICE_ID (
    echo Found device id: "%DEVICE_ID%"
    ) else (
    echo [WARN] No device id found after connect.
    set DEVICE_ID=%PHONE_IP%:%DEBUG_PORT%
    )

    goto RUN_TCPIP

    :RUN_TCPIP
    echo Switching device %DEVICE_ID% to TCP/IP 5555...
    "%ADB%" -s "%DEVICE_ID%" tcpip 5555
    if not errorlevel 1 echo adb -s %DEVICE_ID% tcpip 5555>>"%SUMMARY_FILE%"

    echo Connecting final port: %PHONE_IP%:5555
    "%ADB%" connect %PHONE_IP%:5555
    if not errorlevel 1 echo adb connect %PHONE_IP%:5555>>"%SUMMARY_FILE%"

    echo Disconnecting stale debug port: %PHONE_IP%:%DEBUG_PORT%
    "%ADB%" disconnect %PHONE_IP%:%DEBUG_PORT% >nul 2>&1
    if not errorlevel 1 echo adb disconnect %PHONE_IP%:%DEBUG_PORT%>>"%SUMMARY_FILE%"

    set DEVICE_ID=%PHONE_IP%:5555

    :RUN_SCRCPY
    echo Launching scrcpy completely silent...

    set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"

    echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
    echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

    echo scrcpy --tcpip=%PHONE_IP% %SCRCPY_OPTS%>>"%SUMMARY_FILE%"

    wscript.exe "%VBS_TEMP%"

    timeout /t 1 >nul
    if exist "%VBS_TEMP%" del "%VBS_TEMP%"

    echo Done.
    echo.
    echo Summary of steps run in this instance:
    type "%SUMMARY_FILE%"
    echo.
    echo.
    echo.

    exit /b

    REM end of adbconnect.bat
    --
    My conversations are deep because they cover more tested detail than most do. --- Synchronet 3.22a-Linux NewsLink 1.2