Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #145363 > unrolled thread
| Started by | Marion <marion@facts.com> |
|---|---|
| First post | 2025-03-21 05:55 +0000 |
| Last post | 2025-04-05 22:57 +0000 |
| Articles | 20 on this page of 146 — 21 participants |
Back to article view | Back to comp.sys.mac.system
Tutorial: Working example of removing & re-installing Android system apps from a PC Marion <marion@facts.com> - 2025-03-21 05:55 +0000
A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-24 19:15 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-24 21:09 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 22:55 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-25 08:33 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Tango Romeo <TangoRomero@snope.com> - 2025-03-25 20:09 -0600
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-28 19:50 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Alan <nuh-uh@nope.com> - 2025-03-28 15:13 -0700
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Hank Rogers <Hank@nospam.invalid> - 2025-03-28 18:04 -0500
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Alan <nuh-uh@nope.com> - 2025-03-28 17:33 -0700
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-29 06:35 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-03-29 13:33 +0100
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-29 17:41 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Hank Rogers <Hank@nospam.invalid> - 2025-03-29 16:00 -0500
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-30 06:30 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Alan <nuh-uh@nope.com> - 2025-03-30 17:04 -0700
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Bill Powell <bill@anarchists.org> - 2025-03-31 09:16 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-03-31 11:04 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Isaac Montara <IsaacMontara@nospam.com> - 2025-03-31 11:59 -0400
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-03-31 19:42 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Isaac Montara <IsaacMontara@nospam.com> - 2025-03-31 18:40 -0400
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Peter <confused@nospam.net> - 2025-04-02 09:28 +0100
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Peter <confused@nospam.net> - 2025-04-02 18:10 +0100
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Peter <confused@nospam.net> - 2025-04-03 00:35 +0100
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Peter <confused@nospam.net> - 2025-04-03 06:57 +0100
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Alan <nuh-uh@nope.com> - 2025-03-31 10:49 -0700
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Hank Rogers <Hank@nospam.invalid> - 2025-03-31 18:06 -0500
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Your Name <YourName@YourISP.com> - 2025-04-01 10:55 +1300
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-31 22:29 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-03-31 10:59 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-31 16:05 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-03-31 19:45 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-03-31 22:32 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-02 02:10 +0000
Re: A good thing or a bad thing Richard Kettlewell <invalid@invalid.invalid> - 2025-04-02 09:03 +0100
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 12:58 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Your Name <YourName@YourISP.com> - 2025-04-03 09:34 +1300
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-02 23:38 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Alan <nuh-uh@nope.com> - 2025-04-03 14:15 -0700
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) WolfFan <akwolffan@zoho.com> - 2025-04-04 18:25 -0400
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) WolfFan <akwolffan@zoho.com> - 2025-04-04 18:28 -0400
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-05 00:34 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-07 18:57 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-07 20:34 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 00:45 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-08 00:01 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 02:37 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-08 06:07 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Daniel70 <daniel47@eternal-september.org> - 2025-04-08 19:19 +1000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-08 10:25 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Frankie <frankie@nospam.usa> - 2025-04-08 10:28 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 13:07 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-08 18:00 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-09 12:37 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 20:03 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-11 09:31 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-11 08:57 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-09 12:35 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 20:43 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-11 09:36 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-11 09:29 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-13 14:07 +0200
Re: A good thing or a bad thing Frank Slootweg <this@ddress.is.invalid> - 2025-04-11 17:39 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-11 19:01 +0000
Re: A good thing or a bad thing Arno Welzel <usenet@arnowelzel.de> - 2025-04-13 14:09 +0200
Re: A good thing or a bad thing Arno Welzel <usenet@arnowelzel.de> - 2025-04-13 14:08 +0200
Re: A good thing or a bad thing Frank Slootweg <this@ddress.is.invalid> - 2025-04-13 13:57 +0000
Re: A good thing or a bad thing Arno Welzel <usenet@arnowelzel.de> - 2025-04-14 13:18 +0200
Re: A good thing or a bad thing Arno Welzel <usenet@arnowelzel.de> - 2025-04-14 16:58 +0200
Re: A good thing or a bad thing Frank Slootweg <this@ddress.is.invalid> - 2025-04-14 15:48 +0000
Re: A good thing or a bad thing "Carlos E.R." <robin_listas@es.invalid> - 2025-04-14 22:01 +0200
Android full backup. (was: A good thing or a bad thing) Frank Slootweg <this@ddress.is.invalid> - 2025-04-15 13:18 +0000
Re: Android full backup. "Carlos E.R." <robin_listas@es.invalid> - 2025-04-15 18:22 +0200
Re: Android full backup. Frank Slootweg <this@ddress.is.invalid> - 2025-04-15 18:27 +0000
Re: Android full backup. "Carlos E.R." <robin_listas@es.invalid> - 2025-04-15 23:31 +0200
Re: Android full backup. Paul <nospam@needed.invalid> - 2025-04-15 23:24 -0400
Re: Android full backup. Marion <marion@facts.com> - 2025-04-16 05:24 +0000
Re: Android full backup. Frank Slootweg <this@ddress.is.invalid> - 2025-04-18 17:36 +0000
Re: Android full backup. Alan <nuh-uh@nope.com> - 2025-04-18 10:49 -0700
Re: Android full backup. Marion <marion@facts.com> - 2025-04-25 00:35 +0000
Re: A good thing or a bad thing Daniel70 <daniel47@eternal-september.org> - 2025-04-16 20:53 +1000
Re: A good thing or a bad thing Paul <nospam@needed.invalid> - 2025-04-16 08:28 -0400
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-16 13:26 -0700
Re: A good thing or a bad thing "Carlos E.R." <robin_listas@es.invalid> - 2025-04-16 23:10 +0200
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-16 14:41 -0700
Re: A good thing or a bad thing Hank Rogers <Hank@nospam.invalid> - 2025-04-16 17:54 -0500
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-16 18:52 -0700
Re: A good thing or a bad thing Paul <nospam@needed.invalid> - 2025-04-16 17:24 -0400
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-16 18:52 -0700
Re: A good thing or a bad thing Paul <nospam@needed.invalid> - 2025-04-17 01:15 -0400
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-16 23:45 -0700
Re: A good thing or a bad thing Paul <nospam@needed.invalid> - 2025-04-17 08:26 -0400
Re: A good thing or a bad thing "Carlos E.R." <robin_listas@es.invalid> - 2025-04-17 11:08 +0200
Re: A good thing or a bad thing Paul <nospam@needed.invalid> - 2025-04-17 09:01 -0400
Re: A good thing or a bad thing "Carlos E.R." <robin_listas@es.invalid> - 2025-04-17 21:43 +0200
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-16 13:25 -0700
Re: A good thing or a bad thing "Carlos E.R." <robin_listas@es.invalid> - 2025-04-14 21:56 +0200
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-15 00:26 +0000
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-14 18:10 -0700
Re: A good thing or a bad thing Hank Rogers <Hank@nospam.invalid> - 2025-04-14 21:22 -0500
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-15 16:11 +0000
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-15 09:31 -0700
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-15 17:54 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-15 18:09 +0000
Re: A good thing or a bad thing Alan <nuh-uh@nope.com> - 2025-04-15 11:26 -0700
Re: A good thing or a bad thing Jolly Roger <jollyroger@pobox.com> - 2025-04-15 21:36 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 13:06 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Alan <nuh-uh@nope.com> - 2025-04-08 09:42 -0700
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 22:50 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) vallor <vallor@cultnix.org> - 2025-04-08 22:57 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) vallor <vallor@cultnix.org> - 2025-04-08 22:55 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 01:19 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-09 12:42 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-12 00:18 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-07-12 22:51 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-09 12:39 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Your Name <YourName@YourISP.com> - 2025-04-09 16:24 +1200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 05:35 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Zaidy036 <Zaidy036@air.isp.spam> - 2025-04-09 13:55 -0400
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 21:55 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-09 12:31 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 20:58 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-11 09:39 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-11 09:45 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Arno Welzel <usenet@arnowelzel.de> - 2025-04-09 12:29 +0200
Re: A good thing or a bad thing Frank Slootweg <this@ddress.is.invalid> - 2025-04-09 15:35 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-09 21:21 +0000
Re: A good thing or a bad thing Arno Welzel <usenet@arnowelzel.de> - 2025-04-11 09:40 +0200
Re: A good thing or a bad thing Frank Slootweg <this@ddress.is.invalid> - 2025-04-11 12:00 +0000
Re: A good thing or a bad thing Jolly Roger <jollyroger@pobox.com> - 2025-04-11 15:36 +0000
Re: A good thing or a bad thing Frank Slootweg <this@ddress.is.invalid> - 2025-04-11 17:32 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-11 18:51 +0000
Re: A good thing or a bad thing Jolly Roger <jollyroger@pobox.com> - 2025-04-14 03:32 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-14 05:07 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-11 18:36 +0000
Re: A good thing or a bad thing Marion <marion@facts.com> - 2025-04-12 01:01 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-06 13:18 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Your Name <YourName@YourISP.com> - 2025-04-07 09:45 +1200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-09 21:28 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Hank Rogers <Hank@nospam.invalid> - 2025-04-09 17:39 -0500
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-10 08:02 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-10 13:06 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-10 19:10 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-10 21:35 +0200
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Marion <marion@facts.com> - 2025-04-10 23:15 +0000
Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-05 22:57 +0000
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Marion <marion@facts.com> |
|---|---|
| Date | 2025-04-11 09:29 +0000 |
| Subject | Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) |
| Message-ID | <vtancr$21u2$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #145489 |
On Fri, 11 Apr 2025 09:36:39 +0200, Arno Welzel wrote :
>> The original question was what was *different* & whether it was good or
>> bad, where what's different with iOS is Apple locks every installer to you.
>
> Yes - and?
>
> If you can not copy installer files anyway, what's the matter then if
> they get bound to a specific AppleID?
You bring up a logical assessment which I appreciate that you explained.
Since I'm always sensible and logical, I fully agree with your point.
Given Apple *already* prevents you from ever backing up any iOS installer,
your point is that it's immaterial that Apple *also* locks it to your ID.
(See caveat in the sig.)
However, it still matters that Apple tracks you by that unique insertion.
>> If you happen to have installed on your Android the last known good version
>> of any given app, you can re-install that app on *billions* of Androids.
>
> Yes, *if* you have the APK files.
Again I appreciate that you explain details that both of us are aware of,
but which the vast majority of people out there probably do not know.
We both agree that Google began requiring all new apps to be published
using the Android App Bundle (AAB) format on August 1, 2021.
Luckily, all my last known good versions date from well before then.
But to your point, if my last known good version dates from *after* that
period, and if I received my app from the Google Play Store repository,
then (and only then) would the base APK that is always stored on Android,
not be able to be put onto every Android device on the planet.
For example a base APK on my Samsung Galaxy (if downloaded after August
2021) would likely only work on hardware/software compatible devices.
> Google Play itself does not provide
> the option to install older versions - you can only download the latest
> version of an app which available for your device.
You are correct that Google Play doesn't allow the option of installing
older versions, but when you use the Google Play Store open source
replacement apps, they automatically save *every* version you installed.
<https://i.postimg.cc/c4PrjSwx/aurora19.jpg> Save all APKs during install
The ironic thing is that Google Play could do it too, if it wanted to,
since all the Google Play replacement app is doing is NOT DELETING it.
<https://i.postimg.cc/Z5kdD2rg/aurora04.jpg> APKs autosaved to sdcard
This is why I have *thousands* of APKs stored automatically on Windows.
<https://i.postimg.cc/cJQPvngN/aurora09.jpg> Aurora saves all APKs
> And if your device is
> too old some apps may even not be available any longer, because the
> publishers decided not to support older Android versions etc.
While I agree with you, that's why you autosave every APK you install!
You can grab them and just slide them over to the phone to install them!
<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg> Drag APK from Windows
>> The point not being the sheer number but the fact it's unrestricted re-use.
>> However... that same scenario won't work for iOS owners. And that's bad.
>
> For iOS owners many other things don't work the same way.
> If you don't like that, just don't use it. Problem solved.
I must disagree with your attitude that you feel there's no reason to
understand anything that you simply happen to not like how it works.
The fact is we're discussing HOW things work & what's good/bad about it.
I didn't start this thread topic. I am merely answering the question asked.
Your admonition that if you don't like something, then you have no right to
explain how that something works, is not an attitude that I share with you.
>> Even an iTunes "backup" of that last known good version of an app does not
>> contain a re-usable IPA to that last known good version of that iOS app.
>
> Yes, the same as in Android. Android backups do not backup everything
> and apps installer files will not be backed up at all, just the list
> which app should be installed.
While I understand what you claimed, most people will believe your words as
stated to mean more than what you meant them to mean, so that's a problem.
The fact is Android already automatically saves every APK you install.
That base.apk is *always* there. All you have to do is copy it to the PC.
@echo off
echo Getting list of installed packages...
adb shell pm list packages -f > packages.txt
echo Extracting APK paths and pulling files...
for /F "tokens=1* delims=:" %%A in ('type packages.txt') DO (
if "%%A"=="package" (
for /F "tokens=1 delims== " %%C in ("%%B") DO (
echo Pulling "%%C"
adb pull "%%C" "Pulled_APKs\"
)
)
)
echo Done. APKs have been pulled to the "Pulled_APKs" folder.
del packages.txt
pause
But what you're saying is that the user has to think to do that.
And I agree with that sentiment. Backup strategies have to be planned.
>> The app backup only contains garbage such as meta data & app data.
>> But the app backup (even with iTunes) does NOT contain the full ipa file.
>
> The same applies to Android.
That statement is not correct since the Android base apk is always there.
There are *plenty* of APK extractors on Android which back up the APKs.
Here's one from my own notes when I used to extract all the Android APKs.
ML Manager: APK Extractor Javier Santos V
4.0 star 3.35K reviews 500K+ Downloads
<https://play.google.com/store/apps/details?id=com.javiersantos.mlmanager>
<https://about.javiersantos.me/mlmanager/>
<https://github.com/javiersantos/MLManager>
Files stored by default in internal
MLManager: Settings > Custom folder for extracted APKs
Default: /storage/emulated/0/Android/media/com.javiersantos.mlmanager
It doesn't seem to be able to put them on the sdcard automatically.
Custom: /storage/0000-0001/0001/apk/mlmanager <== does not work
Custom: /storage/emulated/0/0000/apk/mlmanager <== works
>> Every other operating system allows the user to re-install the last known
>> good version after a factory reset (or crash, or whatever)... except Apple.
>
> Nope. Android does not allow to do this either if you do not manually
> extract APK files. And even then you can not be sure of the APK file
> works on another device because the publisher uses AAB for publishing.
We agree that the average user doesn't know what we know so that average
user might not know how to easily back up all the Android APKs like we do.
But that doesn't change the facts as presented in this thread that with
iOS, it's impossible to back up the IPA installer for almost any user.
And that's bad.
--
Note: There are IPA installers you can back up & which there isn't a unique
ID but those are mostly used in the corporate world & Apple restricts them
differently. We're mainly discussing the common user in this thread.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-04-13 14:07 +0200 |
| Subject | Re: A good thing or a bad thing (Was: Tutorial: Working example of removing & re-installing Android system apps from a PC) |
| Message-ID | <m61no1Fi8eqU1@mid.individual.net> |
| In reply to | #145493 |
Marion, 2025-04-11 11:29: > On Fri, 11 Apr 2025 09:36:39 +0200, Arno Welzel wrote : [...] >> Yes, *if* you have the APK files. > > Again I appreciate that you explain details that both of us are aware of, > but which the vast majority of people out there probably do not know. > > We both agree that Google began requiring all new apps to be published > using the Android App Bundle (AAB) format on August 1, 2021. JFTR: I am an app publisher myself. So if I write about Android, keep in mind that I develop software for it ;-) My private "pet project" there (beside professional apps which are provided for our customers): <https://play.google.com/store/apps/details?id=de.arnowelzel.android.periodical> [...] > I must disagree with your attitude that you feel there's no reason to > understand anything that you simply happen to not like how it works. The normal user can do what he wants and use alternative app stores, additional tools, backup APK files. But this is more or less futile. Older app versions may also contain security issues - and this is also a reason *not* to use that, just because you can. And if any user complains, that an old version of my app does not work as expected I will of course tell them to use the latest version since I do *not* support older versions. And if the new version does not work on his/her device any longer - bad luck. I can not support devices which are 8 years or older. [...] > Your admonition that if you don't like something, then you have no right to > explain how that something works, is not an attitude that I share with you. Where did I do that??? I just said, that if you don't like a system as it works, then don't use it. [...] >> Yes, the same as in Android. Android backups do not backup everything >> and apps installer files will not be backed up at all, just the list >> which app should be installed. > > While I understand what you claimed, most people will believe your words as > stated to mean more than what you meant them to mean, so that's a problem. > > The fact is Android already automatically saves every APK you install. But not as part of a backup! > That base.apk is *always* there. All you have to do is copy it to the PC. Sure - but you have to do that manually. > @echo off > echo Getting list of installed packages... > adb shell pm list packages -f > packages.txt Good luck explaining non tech-savvy users how to get "adb" in their console and how to use a console at all. [..] >>> The app backup only contains garbage such as meta data & app data. >>> But the app backup (even with iTunes) does NOT contain the full ipa file. >> >> The same applies to Android. > > That statement is not correct since the Android base apk is always there. Wrong. The DEFAULT ANDROID BACKUP DONE BY GOOGLE ITSELF does not contain it! If you move to a NEW DEVICE the BACKUP will NOT contain the APK for it! -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-04-11 17:39 +0000 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <vtbr52.op8.1@ID-201911.user.individual.net> |
| In reply to | #145489 |
Arno Welzel <usenet@arnowelzel.de> wrote: > Marion, 2025-04-09 22:43: [...] > > Even an iTunes "backup" of that last known good version of an app does not > > contain a re-usable IPA to that last known good version of that iOS app. > > Yes, the same as in Android. Android backups do not backup everything > and apps installer files will not be backed up at all, just the list > which app should be installed. That depends on which backup method is used. For the 'built-in' Backup by Google One method, you're correct. But for example Samsung's Smart Switch program, can/does backup and restore APKs. Also there are many other backup apps for Android, which can also backup/restore APKs. [...]
[toc] | [prev] | [next] | [standalone]
| From | Marion <marion@facts.com> |
|---|---|
| Date | 2025-04-11 19:01 +0000 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <vtbour$ekr$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #145498 |
On 11 Apr 2025 17:39:23 GMT, Frank Slootweg wrote : > Also there are many other backup apps for Android, which can also > backup/restore APKs. Frank is correct in that there are *many* installer backup mechanisms for every common consumer operating system other than for Apple's iOS OS. What's unique about iOS is that it's *impossible* to back up the IPA. And that's bad. We could go deeper though, which is that iMazing will *download* the IPA from the App Store, but now we get back into the issue of it being locked. And that's bad. -- The old iTunes could download IPAs directly from the App Store to your computer. iMazing downloads IPAs from the App Store (associated with your Apple ID) to your computer. Neither modern iTunes nor iMazing directly copies the raw IPA files off of your already installed iOS device during a backup or management process.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-04-13 14:09 +0200 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <m61nsgFi8eqU3@mid.individual.net> |
| In reply to | #145501 |
Marion, 2025-04-11 21:01: > On 11 Apr 2025 17:39:23 GMT, Frank Slootweg wrote : > > >> Also there are many other backup apps for Android, which can also >> backup/restore APKs. > > Frank is correct in that there are *many* installer backup mechanisms for > every common consumer operating system other than for Apple's iOS OS. > > What's unique about iOS is that it's *impossible* to back up the IPA. > And that's bad. So don't use iOS if you don't like it. And if you are on a mission to convince others to also not use iOS - go on, feel free to do so. But stop abusing Android newsgroups for it - thank you! -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-04-13 14:08 +0200 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <m61nq9Fi8eqU2@mid.individual.net> |
| In reply to | #145498 |
Frank Slootweg, 2025-04-11 19:39: > Arno Welzel <usenet@arnowelzel.de> wrote: >> Marion, 2025-04-09 22:43: > [...] > >>> Even an iTunes "backup" of that last known good version of an app does not >>> contain a re-usable IPA to that last known good version of that iOS app. >> >> Yes, the same as in Android. Android backups do not backup everything >> and apps installer files will not be backed up at all, just the list >> which app should be installed. > > That depends on which backup method is used. For the 'built-in' Backup > by Google One method, you're correct. But for example Samsung's Smart > Switch program, can/does backup and restore APKs. Theat's irrelevant. Not everybody uses Samsung devices. So we MUST ONLY talk about the default backup provided by Android itself which is also implemented by LineageOS BTW. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-04-13 13:57 +0000 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <vtgmsh.kkg.1@ID-201911.user.individual.net> |
| In reply to | #145504 |
Arno Welzel <usenet@arnowelzel.de> wrote: > Frank Slootweg, 2025-04-11 19:39: > > > Arno Welzel <usenet@arnowelzel.de> wrote: > >> Marion, 2025-04-09 22:43: > > [...] > > > >>> Even an iTunes "backup" of that last known good version of an app does not > >>> contain a re-usable IPA to that last known good version of that iOS app. > >> > >> Yes, the same as in Android. Android backups do not backup everything > >> and apps installer files will not be backed up at all, just the list > >> which app should be installed. > > > > That depends on which backup method is used. For the 'built-in' Backup > > by Google One method, you're correct. But for example Samsung's Smart > > Switch program, can/does backup and restore APKs. > > Theat's irrelevant. Not everybody uses Samsung devices. So we MUST ONLY > talk about the default backup provided by Android itself which is also > implemented by LineageOS BTW. Nope, we must not. As I said, and you again 'conveniently' dishonestly snipped: <unsnip> Also there are many other backup apps for Android, which can also backup/restore APKs. </unsnip> That's the beauty about a platform like Android, choice. As this is the second time you try to make your point by lying by omission, it's EOD. BTW, I assume that the 'Backup by Google One' method is part of gapps, which is optional in LineageOS, so while it may be implemented for/by LineageOS, it can't be considered "the default backup" for LineageOS. BTW2, While the Samsung Smart Switch *program* on *Windows* probably can only backup/restore a Samsung device, the Smart Switch *app* on *Android* can backup/restore any Android device, that's one of its main purposes.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-04-14 13:18 +0200 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <m64982F397U8@mid.individual.net> |
| In reply to | #145506 |
Frank Slootweg, 2025-04-13 15:57: > Arno Welzel <usenet@arnowelzel.de> wrote: [...] >> Theat's irrelevant. Not everybody uses Samsung devices. So we MUST ONLY >> talk about the default backup provided by Android itself which is also >> implemented by LineageOS BTW. > > Nope, we must not. As I said, and you again 'conveniently' dishonestly > snipped: > > <unsnip> > Also there are many other backup apps for Android, which can also > backup/restore APKs. > </unsnip> That's irrelevant in the context "what does the operating system provide". > That's the beauty about a platform like Android, choice. Sure - but "using a backup app" is not using what Android itself is providing. Google also provides a backup feature in Android itself which also allows to transfer data from one device to another when you switch devices. But as I also explained: APK files are not included, because not every APK file will work on every device, since APK files are device specific packages and not universal installers. Most of the time it works, but there is no guarantee for it and it is much safer to reinstall apps on a new device by downloading it again, so always the correct version will be used. > As this is the second time you try to make your point by lying by > omission, it's EOD. I did not try to make anything. I just explained, how ANDROID ITSELF works. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-04-14 16:58 +0200 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <m64m52F2bvgU1@mid.individual.net> |
| In reply to | #145511 |
Arno Welzel, 2025-04-14 13:18: > Frank Slootweg, 2025-04-13 15:57: [...] >> That's the beauty about a platform like Android, choice. > > Sure - but "using a backup app" is not using what Android itself is > providing. > > Google also provides a backup feature in Android itself which also > allows to transfer data from one device to another when you switch [...] In addition - see here: <https://support.google.com/android/answer/2819582?hl=en> Yes, I agree, that Android has the flexibility to user other methods as well, like backup apps, ADB and so on - but this needs enough experience by the user like how to set up ADB on a computer or how to transfer the backup to another device using USB and so on. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-04-14 15:48 +0000 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <vtjhpd.vbc.1@ID-201911.user.individual.net> |
| In reply to | #145513 |
Arno Welzel <usenet@arnowelzel.de> wrote: > Arno Welzel, 2025-04-14 13:18: > > > Frank Slootweg, 2025-04-13 15:57: > [...] > >> That's the beauty about a platform like Android, choice. > > > > Sure - but "using a backup app" is not using what Android itself is > > providing. I don't think other posters, including 'Marion', were limiting the backup methods to just those in Android itself and neither was/am I. > > Google also provides a backup feature in Android itself which also > > allows to transfer data from one device to another when you switch > [...] > > In addition - see here: > <https://support.google.com/android/answer/2819582?hl=en> Well, 'Backup by Google One' has very limited functionality, for example it does not backup the settings and data of non-Google apps (i.e. Android\data, obb, obj, etc), which makes it basically useless for general backup. Case in point: I have some 40++ *GB* of app data, but my 'Backup by Google One' backup is only 29 *MB*. So yes, 'Backup by Google One' might be useful to *transfer* stuff from an old to a new device, but if your device is totally wiped by some event, you can't *restore* your device from the 'Backup by Google One' backup. Anyway, the context (at least Marion's and mine) was app APK backup/ restore, which - as you say - 'Backup by Google One' doesn't do. > Yes, I agree, that Android has the flexibility to user other methods as > well, like backup apps, ADB and so on - but this needs enough experience > by the user like how to set up ADB on a computer or how to transfer the > backup to another device using USB and so on. The methods I mentioned do not require the user to setup ADB. The Smart Switch Android-to-Windows backup does use a USB-cable, but no ADB. The Smart Switch Android app can transfer to another phone by Wi-Fi or USB and can backup to cloud, SD-card or USB-stick. Yes, (full) Android backup isn't easy, because the supplied 'Backup by Google One' is basically useless, so other additional - and mostly non-Google - software is needed. But app *APK* backup and restore is quite easy, just not built-in.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-04-14 22:01 +0200 |
| Subject | Re: A good thing or a bad thing |
| Message-ID | <m660dlx5ob.ln2@Telcontar.valinor> |
| In reply to | #145514 |
On 2025-04-14 17:48, Frank Slootweg wrote: > Arno Welzel <usenet@arnowelzel.de> wrote: >> Arno Welzel, 2025-04-14 13:18: >> >>> Frank Slootweg, 2025-04-13 15:57: >> [...] >> Yes, I agree, that Android has the flexibility to user other methods as >> well, like backup apps, ADB and so on - but this needs enough experience >> by the user like how to set up ADB on a computer or how to transfer the >> backup to another device using USB and so on. > > The methods I mentioned do not require the user to setup ADB. The > Smart Switch Android-to-Windows backup does use a USB-cable, but no ADB. > The Smart Switch Android app can transfer to another phone by Wi-Fi or > USB and can backup to cloud, SD-card or USB-stick. That's a Samsung app, I understand. What about a generic full backup app, non adb? For any operating system, not Windows only? Using my Motorola phone I can transfer from old phone to new phone most things. But not to disk. And I don't remember if all data is transferred. Photos, maps... -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-04-15 13:18 +0000 |
| Subject | Android full backup. (was: A good thing or a bad thing) |
| Message-ID | <vtltcc.mok.1@ID-201911.user.individual.net> |
| In reply to | #145517 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2025-04-14 17:48, Frank Slootweg wrote: > > Arno Welzel <usenet@arnowelzel.de> wrote: > >> Arno Welzel, 2025-04-14 13:18: > >> > >>> Frank Slootweg, 2025-04-13 15:57: > >> [...] > > > >> Yes, I agree, that Android has the flexibility to user other methods as > >> well, like backup apps, ADB and so on - but this needs enough experience > >> by the user like how to set up ADB on a computer or how to transfer the > >> backup to another device using USB and so on. > > > > The methods I mentioned do not require the user to setup ADB. The > > Smart Switch Android-to-Windows backup does use a USB-cable, but no ADB. > > The Smart Switch Android app can transfer to another phone by Wi-Fi or > > USB and can backup to cloud, SD-card or USB-stick. > > That's a Samsung app, I understand. What about a generic full backup > app, non adb? For any operating system, not Windows only? I have no real suggestion/solution, other than adb (and MTP). An (non-Google) Android app cannot provide a solution, because on a non-rooted phone, it can't backup the /Internal storage/Android folders (data, obb?, others?), which contains the settings and data of all the apps. Because I have a Samsung phone, I could use the Samsung Smart Switch program on Windows, but that is not flexible enough for backing up what you want and not backing up what you don't want. It is oriented in categories instead of in folders and for some categories, it's all or nothing. > Using my Motorola phone I can transfer from old phone to new phone most > things. But not to disk. And I don't remember if all data is > transferred. Photos, maps... You could try the 'Smart Switch Mobile' [1] [2] Android app. For transfer to another device, it runs on any (i.e. also non-Samsung) device. I don't know if it then can also make backup (to cloud, SD-card or USB-stick). The reference [2] implies it can. (I do no longer have a recent/working non-Samsung device to try.) Same for the Smart Switch PC program for Windows [2]. Probably only works if the source is a Samsung device (reference [2] only works if you specify 'GALAXY'), but you can try. For a non-automated backup you can use MTP. With MTP you *can* access the /Internal storage/Android folders. For example in Windows File Explorer, this accesses the folder which contains the OsmAnd+ maps: This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible in File Explorer, it's not part of the normal file system, nor accessible as a Network Share, so you can't use normal copy or backup utilities. (Perhaps in Windows PowerShell one can 'program'/control File Explorer? No idea.) The MTP method should also work in Linux (and on macOS? and on ChromeOS?). FWIW, because of these limitations, I no longer bother with full Android backup. I only backup the folders which *are* accessible on a non-rooted device. For all my apps, at least the important ones, I investigate if I can recover/recreate the settings or/and data, if I lose them. For example in OsmAnd+ you can export settings, etc, and backup those and all maps can be reloaded. For apps which have complicated settings, which can not be exported/backed-up, I document which settings I have changed. Some apps have their own backup methods (for example WhatsApp). Some apps only need account credentials. Etc. etc.. Of course this whole mechanism is documented in a file which *is* backed up! :-) Sofar, in nearly 12 years, I haven't had any major mishaps, so I'll continue to use my "Can not backup, so prepare to recover recreate.' method. Hope this helps. [1] <https://play.google.com/store/apps/details?id=com.sec.android.easyMover> [2] <https://www.samsung.com/us/apps/smart-switch/> See 'How to transfer' -> GALAXY -> Backup and restore from PC or Mac -> Windows For using the Smart Switch Mobile Android app to *backup* (not transfer), see 'Other Android' -> 'Backup and restore from external storage'
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-04-15 18:22 +0200 |
| Subject | Re: Android full backup. |
| Message-ID | <umd2dlx8kv.ln2@Telcontar.valinor> |
| In reply to | #145527 |
On 2025-04-15 15:18, Frank Slootweg wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2025-04-14 17:48, Frank Slootweg wrote: >>> Arno Welzel <usenet@arnowelzel.de> wrote: >>>> Arno Welzel, 2025-04-14 13:18: >>>> >>>>> Frank Slootweg, 2025-04-13 15:57: >>>> [...] >> >> >>>> Yes, I agree, that Android has the flexibility to user other methods as >>>> well, like backup apps, ADB and so on - but this needs enough experience >>>> by the user like how to set up ADB on a computer or how to transfer the >>>> backup to another device using USB and so on. >>> >>> The methods I mentioned do not require the user to setup ADB. The >>> Smart Switch Android-to-Windows backup does use a USB-cable, but no ADB. >>> The Smart Switch Android app can transfer to another phone by Wi-Fi or >>> USB and can backup to cloud, SD-card or USB-stick. >> >> That's a Samsung app, I understand. What about a generic full backup >> app, non adb? For any operating system, not Windows only? > > I have no real suggestion/solution, other than adb (and MTP). > > An (non-Google) Android app cannot provide a solution, because on a > non-rooted phone, it can't backup the /Internal storage/Android folders > (data, obb?, others?), which contains the settings and data of all the > apps. > > Because I have a Samsung phone, I could use the Samsung Smart Switch > program on Windows, but that is not flexible enough for backing up what > you want and not backing up what you don't want. It is oriented in > categories instead of in folders and for some categories, it's all or > nothing. > >> Using my Motorola phone I can transfer from old phone to new phone most >> things. But not to disk. And I don't remember if all data is >> transferred. Photos, maps... > > You could try the 'Smart Switch Mobile' [1] [2] Android app. For > transfer to another device, it runs on any (i.e. also non-Samsung) > device. I don't know if it then can also make backup (to cloud, SD-card > or USB-stick). The reference [2] implies it can. (I do no longer have a > recent/working non-Samsung device to try.) > > Same for the Smart Switch PC program for Windows [2]. Probably only > works if the source is a Samsung device (reference [2] only works if you > specify 'GALAXY'), but you can try. > > For a non-automated backup you can use MTP. With MTP you *can* access > the /Internal storage/Android folders. For example in Windows File > Explorer, this accesses the folder which contains the OsmAnd+ maps: MTP is what I do. Sometimes I have used a WiFi file server app on the phone instead. Sometimes I found that one can see files the other doesn't, but I don't remember which. > > This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files > > But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible > in File Explorer, it's not part of the normal file system, nor > accessible as a Network Share, so you can't use normal copy or backup > utilities. (Perhaps in Windows PowerShell one can 'program'/control File > Explorer? No idea.) In Linux we can access the filesystem. Once I tell the equivalent of the file explorer to access the phone, then it is also accessible under: /run/user/1000/gvfs/mtp:host=motorola_moto_g52_SOME_LETTERS for any app. This is using with a gtk desktop, with KDE it is somewhere else. Then I can use rsync and copy links to the files in the previous backup. > > The MTP method should also work in Linux (and on macOS? and on > ChromeOS?). > > FWIW, because of these limitations, I no longer bother with full > Android backup. I only backup the folders which *are* accessible on a > non-rooted device. > > For all my apps, at least the important ones, I investigate if I can > recover/recreate the settings or/and data, if I lose them. For example > in OsmAnd+ you can export settings, etc, and backup those and all maps > can be reloaded. For apps which have complicated settings, which can not > be exported/backed-up, I document which settings I have changed. Some > apps have their own backup methods (for example WhatsApp). Some apps > only need account credentials. Etc. etc.. Of course this whole mechanism > is documented in a file which *is* backed up! :-) > > Sofar, in nearly 12 years, I haven't had any major mishaps, so I'll > continue to use my "Can not backup, so prepare to recover recreate.' > method. One phone suddenly died on me, the display went blank, IIRC. Another one died when I took a swim on the sea. Both predated Android, had simply contacts, SMS, and photos of limited quality. They needed an special cable to share the photos and special software. > > Hope this helps. > > [1] > <https://play.google.com/store/apps/details?id=com.sec.android.easyMover> > > [2] > <https://www.samsung.com/us/apps/smart-switch/> > See 'How to transfer' -> GALAXY -> Backup and restore from PC or Mac -> > Windows > For using the Smart Switch Mobile Android app to *backup* (not > transfer), see 'Other Android' -> 'Backup and restore from external > storage' -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-04-15 18:27 +0000 |
| Subject | Re: Android full backup. |
| Message-ID | <vtmffn.1e8.1@ID-201911.user.individual.net> |
| In reply to | #145529 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2025-04-15 15:18, Frank Slootweg wrote: [...] > > For a non-automated backup you can use MTP. With MTP you *can* access > > the /Internal storage/Android folders. For example in Windows File > > Explorer, this accesses the folder which contains the OsmAnd+ maps: > > MTP is what I do. Sometimes I have used a WiFi file server app on the > phone instead. Sometimes I found that one can see files the other > doesn't, but I don't remember which. Yes, I have also found such servers, but none for recent Android versions (10 and higher), which can access the /Internal storage/Android folders. > > This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files > > > > But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible > > in File Explorer, it's not part of the normal file system, nor > > accessible as a Network Share, so you can't use normal copy or backup > > utilities. (Perhaps in Windows PowerShell one can 'program'/control File > > Explorer? No idea.) > > In Linux we can access the filesystem. Once I tell the equivalent of the > file explorer to access the phone, then it is also accessible under: > > /run/user/1000/gvfs/mtp:host=motorola_moto_g52_SOME_LETTERS > > for any app. This is using with a gtk desktop, with KDE it is somewhere > else. > > Then I can use rsync and copy links to the files in the previous backup. Could you give an example (Linux) 'cp' command which shows what the source and destination paths look like? In Windows you can't specify a source path for a 'copy', etc., because such a path does not exist for MTP, so - being an old Unix/UNIX and current GNU user - I am interested what it looks like on Linux (for MTP). Or is the source just a path relative to /run/user/1000/gvfs/mtp? [...]
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-04-15 23:31 +0200 |
| Subject | Re: Android full backup. |
| Message-ID | <1rv2dlxmue.ln2@Telcontar.valinor> |
| In reply to | #145534 |
On 2025-04-15 20:27, Frank Slootweg wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2025-04-15 15:18, Frank Slootweg wrote: > [...] >>> For a non-automated backup you can use MTP. With MTP you *can* access >>> the /Internal storage/Android folders. For example in Windows File >>> Explorer, this accesses the folder which contains the OsmAnd+ maps: >> >> MTP is what I do. Sometimes I have used a WiFi file server app on the >> phone instead. Sometimes I found that one can see files the other >> doesn't, but I don't remember which. > > Yes, I have also found such servers, but none for recent Android > versions (10 and higher), which can access the /Internal storage/Android > folders. I have not tried recently. > >>> This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files >>> >>> But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible >>> in File Explorer, it's not part of the normal file system, nor >>> accessible as a Network Share, so you can't use normal copy or backup >>> utilities. (Perhaps in Windows PowerShell one can 'program'/control File >>> Explorer? No idea.) >> >> In Linux we can access the filesystem. Once I tell the equivalent of the >> file explorer to access the phone, then it is also accessible under: >> >> /run/user/1000/gvfs/mtp:host=motorola_moto_g52_SOME_LETTERS >> >> for any app. This is using with a gtk desktop, with KDE it is somewhere >> else. >> >> Then I can use rsync and copy links to the files in the previous backup. > > Could you give an example (Linux) 'cp' command which shows what the > source and destination paths look like? cp /run/user/1000/gvfs/mtp\:host\=motorola_moto_g52_ZLETTERS/Almacenamiento\ interno\ compartido/DCIM/Camera/ /home/cer/Photos The trick is that "gvfs" means something virtual filesystem. The G could be gnome or gtk, dunno. > In Windows you can't specify a source path for a 'copy', etc., because > such a path does not exist for MTP, so - being an old Unix/UNIX and > current GNU user - I am interested what it looks like on Linux (for > MTP). > > Or is the source just a path relative to /run/user/1000/gvfs/mtp? > > [...] It is an emulation layer. MTP does not support every operation a true filesystem does. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-04-15 23:24 -0400 |
| Subject | Re: Android full backup. |
| Message-ID | <vtn7t5$19q5v$1@dont-email.me> |
| In reply to | #145536 |
On Tue, 4/15/2025 5:31 PM, Carlos E.R. wrote: > On 2025-04-15 20:27, Frank Slootweg wrote: >> In Windows you can't specify a source path for a 'copy', etc., because >> such a path does not exist for MTP, so - being an old Unix/UNIX and >> current GNU user - I am interested what it looks like on Linux (for >> MTP). >> >> Or is the source just a path relative to /run/user/1000/gvfs/mtp? >> >> [...] > > It is an emulation layer. MTP does not support every operation a true filesystem does. MTP supports objects, and a read and write operation on those objects. Whereas MTPfs is the FUSE file system (created as a wrapper, without any control over or conversation with the designers of MTP). An ordinary file system, would work with a partition and a physical layer. That's why it needs more disk operating commands at that physical layer. MTP does exactly what is required of it. It is a "minimalist" design, which is "over-minimalized". It is inefficient. MTPfs would be an attempt to try to fix it, from a distance. But doing all this flopping about, is just bad. It should be a case study for a comp.sci class. You'll notice Google tried to fix it, to fix one of the worst aspects of it -- and that hints, if there had been more industry input in the first place, it would not have been such a pudgy disaster. Paul
[toc] | [prev] | [next] | [standalone]
| From | Marion <marion@facts.com> |
|---|---|
| Date | 2025-04-16 05:24 +0000 |
| Subject | Re: Android full backup. |
| Message-ID | <vtneuh$qa$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #145527 |
On 15 Apr 2025 13:18:40 GMT, Frank Slootweg wrote : > This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files > > But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible > in File Explorer, it's not part of the normal file system, nor > accessible as a Network Share, so you can't use normal copy or backup > utilities. (Perhaps in Windows PowerShell one can 'program'/control File > Explorer? No idea.) I will agree with anyone who says anything logically sensible, where I agree with Frank that there must be a DIY backup mechanism to Windows. On the one topic of the paradoxical observation that both Frank Slootweg and I have experienced of what can be "seen" by the PC vs the phone... <https://i.postimg.cc/1zrmSmQc/davroot.jpg> Windows can see Android root! I also have been surprised when the PC can see *far* more of the Android file system than the (non rooted) Android device itself can see. <https://i.postimg.cc/Zngy0SGT/filesys03.jpg> Look at /etc/resolv.conf Sure, we all know ADB can back up the system /etc/hosts file but even without ADB, I can read (and write) to far more of the Android file system from the PC than from the phone itself. From the Windows command line! <https://i.postimg.cc/nzFmPTKt/filesys04.jpg> cmd line access to /etc For example, when I mount the Android as a Windows drive letter, I can read "almost" the entire system (not all of it - but a lot more than you'd expect). And I can write to some of the system filesys too I think. <https://i.postimg.cc/PJF1ZZwn/filesys05.jpg> Look at the dnsproxy file In summary, given my observation that when mounting an Android filesystem as a drive letter on Windows that you can see far more than you'd expect to see, one possible backup mechanism might be to use a Windows copy script. <https://i.postimg.cc/2SxM8V16/rootfilesystem.jpg> Windows root access!
[toc] | [prev] | [next] | [standalone]
| From | Frank Slootweg <this@ddress.is.invalid> |
|---|---|
| Date | 2025-04-18 17:36 +0000 |
| Subject | Re: Android full backup. |
| Message-ID | <vtu9jk.jrs.1@ID-201911.user.individual.net> |
| In reply to | #145538 |
Marion <marion@facts.com> wrote: > On 15 Apr 2025 13:18:40 GMT, Frank Slootweg wrote : > > > > This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files > > > > But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible > > in File Explorer, it's not part of the normal file system, nor > > accessible as a Network Share, so you can't use normal copy or backup > > utilities. (Perhaps in Windows PowerShell one can 'program'/control File > > Explorer? No idea.) > > I will agree with anyone who says anything logically sensible, where I > agree with Frank that there must be a DIY backup mechanism to Windows. > > On the one topic of the paradoxical observation that both Frank Slootweg > and I have experienced of what can be "seen" by the PC vs the phone... > <https://i.postimg.cc/1zrmSmQc/davroot.jpg> Windows can see Android root! > > I also have been surprised when the PC can see *far* more of the Android > file system than the (non rooted) Android device itself can see. > <https://i.postimg.cc/Zngy0SGT/filesys03.jpg> Look at /etc/resolv.conf > > Sure, we all know ADB can back up the system /etc/hosts file but even > without ADB, I can read (and write) to far more of the Android file system > from the PC than from the phone itself. From the Windows command line! > <https://i.postimg.cc/nzFmPTKt/filesys04.jpg> cmd line access to /etc > > For example, when I mount the Android as a Windows drive letter, I can read > "almost" the entire system (not all of it - but a lot more than you'd > expect). And I can write to some of the system filesys too I think. > <https://i.postimg.cc/PJF1ZZwn/filesys05.jpg> Look at the dnsproxy file > > In summary, given my observation that when mounting an Android filesystem > as a drive letter on Windows that you can see far more than you'd expect to > see, one possible backup mechanism might be to use a Windows copy script. > <https://i.postimg.cc/2SxM8V16/rootfilesystem.jpg> Windows root access! Yes, an app on Android - in your case the WebDAV Server - can see part/most of the *root* file system, but it can't look in the *app-private data areas*: Internal storage\Android\data, etc.. So, as your last screenshot shows, you can look into the com.<name> folders of some apps, but you will find that those are only *built-in* apps, i.e. the ones which came with the phone. You can't get into the Internal storage\Android\data\com.<name> folders of *user-installed* apps. So this method is no solution for Android full backup, because it can't backup the most important part, the user data and settings.
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-04-18 10:49 -0700 |
| Subject | Re: Android full backup. |
| Message-ID | <vtu3at$3h0ve$1@dont-email.me> |
| In reply to | #145555 |
On 2025-04-18 10:36, Frank Slootweg wrote: > Marion <marion@facts.com> wrote: >> On 15 Apr 2025 13:18:40 GMT, Frank Slootweg wrote : >> >> >>> This PC\Frank's Galaxy A51\Internal storage\Android\data\net.osmand.plus\files >>> >>> But 'This PC\Frank's Galaxy A51\Internal storage' is only accessible >>> in File Explorer, it's not part of the normal file system, nor >>> accessible as a Network Share, so you can't use normal copy or backup >>> utilities. (Perhaps in Windows PowerShell one can 'program'/control File >>> Explorer? No idea.) >> >> I will agree with anyone who says anything logically sensible, where I >> agree with Frank that there must be a DIY backup mechanism to Windows. >> >> On the one topic of the paradoxical observation that both Frank Slootweg >> and I have experienced of what can be "seen" by the PC vs the phone... >> <https://i.postimg.cc/1zrmSmQc/davroot.jpg> Windows can see Android root! >> >> I also have been surprised when the PC can see *far* more of the Android >> file system than the (non rooted) Android device itself can see. >> <https://i.postimg.cc/Zngy0SGT/filesys03.jpg> Look at /etc/resolv.conf >> >> Sure, we all know ADB can back up the system /etc/hosts file but even >> without ADB, I can read (and write) to far more of the Android file system >> from the PC than from the phone itself. From the Windows command line! >> <https://i.postimg.cc/nzFmPTKt/filesys04.jpg> cmd line access to /etc >> >> For example, when I mount the Android as a Windows drive letter, I can read >> "almost" the entire system (not all of it - but a lot more than you'd >> expect). And I can write to some of the system filesys too I think. >> <https://i.postimg.cc/PJF1ZZwn/filesys05.jpg> Look at the dnsproxy file >> >> In summary, given my observation that when mounting an Android filesystem >> as a drive letter on Windows that you can see far more than you'd expect to >> see, one possible backup mechanism might be to use a Windows copy script. >> <https://i.postimg.cc/2SxM8V16/rootfilesystem.jpg> Windows root access! > > Yes, an app on Android - in your case the WebDAV Server - can see > part/most of the *root* file system, but it can't look in the > *app-private data areas*: Internal storage\Android\data, etc.. > > So, as your last screenshot shows, you can look into the com.<name> > folders of some apps, but you will find that those are only *built-in* > apps, i.e. the ones which came with the phone. > > You can't get into the Internal storage\Android\data\com.<name> > folders of *user-installed* apps. > > So this method is no solution for Android full backup, because it > can't backup the most important part, the user data and settings. Imagine that: Arlen not speaking "only facts".
[toc] | [prev] | [next] | [standalone]
| From | Marion <marion@facts.com> |
|---|---|
| Date | 2025-04-25 00:35 +0000 |
| Subject | Re: Android full backup. |
| Message-ID | <vuelbo$2tuj$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #145555 |
On 18 Apr 2025 17:36:47 GMT, Frank Slootweg wrote : > Yes, an app on Android - in your case the WebDAV Server - can see > part/most of the *root* file system, but it can't look in the > *app-private data areas*: Internal storage\Android\data, etc. Yes. That's the part that initially surprised me when I saw that. The WebDAV app can see more than the file manager apps can see. Even some file managers can see more than other file managers. I'd have thought it would be more consistent. As it is, we have to try every file manager to see which is best. I just counted mine. I have twenty file managers, in this order. RoundSync MiX ZArchiver Ghost Commander SMTFile Manager MK Explorer FX Explorer Samsung MyFiles Amaze Amaze Utilities X-plore OI File Manager Material Files Files.nbu Files.marc Explorer Simple Explorer Solid Explorer Cx File Explore Dir > So, as your last screenshot shows, you can look into the com.<name> > folders of some apps, but you will find that those are only *built-in* > apps, i.e. the ones which came with the phone. Oh. Interesting observation. I hadn't noticed what the delta was. Thanks for that astute observation. > You can't get into the Internal storage\Android\data\com.<name> > folders of *user-installed* apps. Yeah. I knew it wasn't everything. But I didn't know what was protected. > So this method is no solution for Android full backup, because it > can't backup the most important part, the user data and settings. Agreed. I hope I didn't sound like I was suggesting it for a FULL backup. I just meant you can back up more than what you see in a typical file manager. And you can back up using a batch file with the drive letter such as C:\> robocopy P:\ <destination> /E /COPYALL (Assuming your sdcard, for example, is mounted as drive "P:" on Win10.) Thanks for the clarifications. I will agree with anyone who makes sensible statements just as I disagree with anyone who doesn't (which could be the same person at any given time - which I find odd that other people find that even-keeled attitude strange to them). I'm not religious that way. If God tells me the truth, I believe it & thank him. If God tells a lie, I confront him. What matters to me isn't the person - but what they say. Each interaction is water under the bridge. The next interaction starts the process anew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web