How complete is the APK that Android saves for every app on the phone?

[Incubus]

Android never deletes the APK for any installed app.
The APK is saved whether or not the app came with the phone.

But is that APK complete enough to install on another Android?

No matter what, the APK can be extracted as explained in this post below.
https://groups.google.com/g/comp.mobile.android/c/F49T9WQSh-E/m/XRAeLgWPAAAJ

But I'm not sure if that APK is "complete enough" to work on any phone.

If not, what can someone do now to get a full APK (whatever that means in
Android/Google technical terms) so that this full apk can be saved (at the
time of installation) for each app for subsequent use on all new phones?

[Andy Burns]

Incubus wrote:

> is that APK complete enough to install on another Android?

maybe not, for a couple of years apps can be split into bundles with
each device deciding whether it installs different parts of the bundle
at install time, or when needed at runtime ...

the splits can be based on cpu architecture, user's language, screen
resolution etc

[Incubus]

Have you any suggestion for an app that is now installed as an AAB to test?

I'm not sure what happens with the AAB files - are they saved as an APK?
https://www.thurrott.com/dev/252614/google-is-replacing-android-apk-with-aab
"Google announced today that it is replacing the Android Package (APK)
application package format for Android with the Android App Bundle (AAB)
effective this August and in tandem with the release of Android 12."

However, even before Google made that change to include AAB (along with
APK?) I think what gets saved as an APK by Android, by default, is just the
specific architecture of the phone the APK is installed on. Which, while it
can be extracted, will be useless on a different architecture. Right?

But I'm not fully sure an architecture-specific APK is what is being saved.

I guess the way around it is to always manually dig up the full APK, which
for the FOSS apps won't be too hard to find - but it will be nigh high
impossible to find the original APK for many apps on the Google Play Store.

Is there any easy way to tell if an APK in front of you is the "full" APK?

[VanguardLH]

Incubus <u953...@gmail.com> wrote:

> Android never deletes the APK for any installed app.

> https://groups.google.com/g/comp.mobile.android/c/F49T9WQSh-E/m/XRAeLgWPAAAJ

That citation is just you, so you're referencing your own claim. No
need to wander off into Google Groups to read that article which is the
GG copy of the Usenet article in this newsgroup.

Subject: How to move app from old phone to new phone?
Started by: micky
MID: <51tjcip74rrguo332...@4ax.com> (for micky's post)
MID: <uadolh$3p7v$1...@dont-email.me> (for your post in that thread)

Most NNTP clients can search by MID to find a post. No need to involve
Google Groups.

The APK (Android Package Kit, aka installer file) is only needed for
distribution and installation as it is the compressed archive (ZIP) into
which the installation files are stored. Once installed, the APK is
superfluous, and a waste of space. The APK contains all the files an
app needs to function: all code (.dex files), certificates, assets,
resources, and manifest file. The installed app does not use the APK.
The APK must have all the files necessary to run the app.

If uninstalling the app did not also delete its APK file, eventually
every Android user would run out of storage space with ghost files. The
compressed archive file may be small, but many users install *TONS* of
apps which they keep regardless of how often they are used, never
delete, or just trial lots of apps to uninstall if they decide they
don't like the apps. If you don't use the Play Store app & site to
manage your apps, like you download and install from elsewhere, well,
then you delegated yourself as the sysadmin of your phone, so it's up to
you to get the APK, and to do cleanup after uninstall.

Or, maybe what you meant to say is the APK installer file for an app
still installed on the old phone will still be present to copy it
elsewhere to install on another phone. You said "never deletes", and
that is incorrect.

Different versions of Android have different features. Newer Android
versions drop old (deprecated) features. So, the APK you acquire must
have the requisite support for the app it delivers. The APK is just a
file. The Play Store checks which APK gets delivered to your phone to
check if the manifest for the APK says the app works with your phone
(and why you may see the Store say the app is incompatible with your
phone, especially if it is an old version of Android), and determines
which APK to deliver to you. Not only may an app be Android version
dependent, it may also be device dependent. A compass app is worthless
on a phone without a magnometer. Some APIs became available only after
a minimum version of Android.

https://developer.android.com/guide/practices/compatibility

You can use an app tool to find out what the manifests for installed
apps state are their minimum supported Android version.

https://www.ghacks.net/2016/10/24/find-out-which-version-of-android-your-apps-support/
https://play.google.com/store/search?q=appchecker
"displays the TargetAPI of all your installed apps"
https://kroegerama.com/development/android/app-checker
"Displays the AndroidManifest.xml of any app."
Adware due to the ad banner.
Opine: Apps become malware if the app author allows fullscreen ads
which block further use of your phone until the ad is dismissed. The
app author must not just copy Google's code for their ads, but ensure
those ads are restricted to within the banner, and never allow
fullscreen ads.
Did not see a link to a payware version of this app to get rid of ads.
Sometimes app devs get more revenue from ads than they do from payware
versions of their apps. Other apps by the same author are payware, so
not sure why there isn't a payware version for this app. There are
probably other apps (I didn't check) to show the TargetAPI from the
manifest of installed apps.

You can copy the APK to another phone, but that doesn't mean the app,
after extraction, will [fully] function on the other phone. The Store
takes care of determining if your phone (registered in your Google
account) is compatible with an app. If you get the APK from elsewhere,
it's up to you to know what the app's manifest declares for compatible
devices. For example, if you use apkmirror.com, the description of an
app should tell you which architecture, minimum Android version, and
screen DPI are required for an app. If you need the app to function on
an older Android version, you have to keep drilling to the old versions
of the app to find one that supports your old OS.

There are many APK manager apps available; for example:

https://play.google.com/store/apps/details?id=com.javiersantos.mlmanager
(There is a payware version of this app, but both freeware and payware
app pages give almost no info on the apps, like what the paid Pro
version gives over the free version, and neither does the dev's site.
So, I have no idea how this author lets you "share" an APK.)

You could, for example, get an Android update that prevents some
previously installed apps from running, because the update, especially
if major, can result in old features getting lost in the OS update.
Besides a minimum Android version required by an app, there may also be
a maximum Android version for an app. With changes in the feature set
for Android versions, your already installed apps may not run, or some
of their features are unusable, when you upgrade the OS.

[Incubus]

On 2023-08-02, VanguardLH <V...@nguard.LH> wrote:
> Most NNTP clients can search by MID to find a post. No need to involve
> Google Groups.

You don't seem to understand the value inherent in a normal search engine:
http://groups.google.com/g/comp.mobile.android

Versus whatever search engine is provided inside any given newsreader app.

While that's probably correct, the problem with the message id is that you
have to know the message id, which a search on the Internet doesn't always
provide (and certainly Google Groups' searches no longer provide headers).

The advantage of the Google Groups Usenet search is that it's dejanews.
Which is a "normal" search engine (much like http://google.com is).

You don't need to use a Howard Knight web site to find an article by MID.
http://al.howardknight.net/

Nor do you need to learn how each newsreader does a search by keyword.
You simply search normally using groups.google.com/g/name.of.the.newsgroup

> The APK (Android Package Kit, aka installer file) is only needed for
> distribution and installation as it is the compressed archive (ZIP) into
> which the installation files are stored. Once installed, the APK is
> superfluous, and a waste of space.

Ask Andy Burns about that APK. It's stored on the Android phone.
For _every_ app that exists on the Android phone.

It's a 1:1 relationship.
1. App is installed
2. APK is saved

If the app is installed, there is an APK for that app which is also saved.
The only question is what is inside that APK.
a. Is it the full installer for every architecture?
b. Or is it the minor installer for just the one architecture?

I don't know.
Do you?

> The APK contains all the files an
> app needs to function: all code (.dex files), certificates, assets,
> resources, and manifest file. The installed app does not use the APK.
> The APK must have all the files necessary to run the app.

Yes. But. You don't appear to understand the question, mainly because
you're guessing (assuming) that the APK is NOT saved for every app.

It is.
Andy Burns understood the question.

That APK which is saved with _every_ app can either be
a. A full APK for all architectures, or,
b. A partial APK for only the one architecture (of the phone).

Big difference.
That's why the question is being asked.

You can't guess at the answer.

It's either the full installer.
Or it's an architecture-specific installer.

The reason that matters is extracting that saved free APK is no different
than just copying it - but if it's not the full installer - it might not
work on the next phone that someone tries to run that extracted APK on.

> If uninstalling the app did not also delete its APK file, eventually
> every Android user would run out of storage space with ghost files.

I don't think anyone said or even intimated that when you Uninstall an app,
that the APK that was saved with that app doesn't go away. It does.

There's a (minor) complication that you can uninstall an app for a user
(using adb for example) while the app is still installed as root (in which
case the APK will remain even if the app was uninstalled for the user).

In short, always, if the app is installed, the APK is saved by Android.
In general, if the app is uninstalled, the APK is removed by Android.

> compressed archive file may be small, but many users install *TONS* of
> apps which they keep regardless of how often they are used, never
> delete, or just trial lots of apps to uninstall if they decide they
> don't like the apps. If you don't use the Play Store app & site to
> manage your apps, like you download and install from elsewhere, well,
> then you delegated yourself as the sysadmin of your phone, so it's up to
> you to get the APK, and to do cleanup after uninstall.

It doesn't seem like you understand that on _every_ Android phone, no
matter _how_ you choose to obtain and install applications, the APK is
saved.

The only question - which is the question inherent in this thread, is
a. Is that saved APK a full installer? ... or ...
b. Is that saved APK only a partial architecture-specific installer?

> Or, maybe what you meant to say is the APK installer file for an app
> still installed on the old phone will still be present to copy it
> elsewhere to install on another phone. You said "never deletes", and
> that is incorrect.

You won't believe me so ask someone else what I'm talking about.
Ask Andy Burns.

Clearly he understood every app ever installed saved the APK when it did.
Even system apps that came pre-configured on the phone already did this.\

How the heck do you think all these extractors work anyway?
https://play.google.com/store/search?q=apk%20extractor&c=apps

They're just a robocopy app that is smart enough to find all these APKs
scattered about on your Android file system in the key system areas.

> Different versions of Android have different features. Newer Android
> versions drop old (deprecated) features. So, the APK you acquire must
> have the requisite support for the app it delivers.

Um... that's the entire point of asking the question in the first place.

> The APK is just a file.

Yes. But it could be a full architecture file or only a sub variant.
That's what the question is asking.

> The Play Store checks which APK gets delivered to your phone to
> check if the manifest for the APK says the app works with your phone
> (and why you may see the Store say the app is incompatible with your
> phone, especially if it is an old version of Android), and determines
> which APK to deliver to you.

Not every app is installed by the Google Play Store, and, in fact, the more
someone knows about Android, the fewer apps he uses from that repository.

Many times the app is installed directly from an APK which was downloaded
off the Internet for example, oh, say, from GitHub or SourceForge.

Have you ever heard of them?
They have Android apps also.

So does F-Droid.

> Not only may an app be Android version
> dependent, it may also be device dependent.

This is the reason for the question in the first place.

> A compass app is worthless
> on a phone without a magnometer. Some APIs became available only after
> a minimum version of Android.
> https://developer.android.com/guide/practices/compatibility
>
> You can use an app tool to find out what the manifests for installed
> apps state are their minimum supported Android version.

Yes. A good one is the Muntashirakon. It's the best, in fact.
https://github.com/MuntashirAkon/AppManager/releases

And it's NOT on the Google Play Store either. But it is on F-Droid.
https://f-droid.org/en/packages/io.github.muntashirakon.AppManager/

> https://www.ghacks.net/2016/10/24/find-out-which-version-of-android-your-apps-support/
> https://play.google.com/store/search?q=appchecker
> "displays the TargetAPI of all your installed apps"
> https://kroegerama.com/development/android/app-checker
> "Displays the AndroidManifest.xml of any app."

This can be done with Muntashirakon I believe, but I'd have to check.

> You can copy the APK to another phone, but that doesn't mean the app,
> after extraction, will [fully] function on the other phone.

Again, that's the entire reason for asking the question in the first place.

> The Store
> takes care of determining if your phone (registered in your Google
> account) is compatible with an app.

The more you know about Android, the less you will be using the Google Play
Store, simply because Google limits what apps can do when it's found there.

An example of where Google limits what an app can do when it's on there is
https://play.google.com/store/apps/details?id=eu.faircode.netguard

Nobody gets that app from the Google Play Store.

They get it from outside the Google Play Store, like perhaps from here.
https://www.netguard.me/

Which says to get it from here (because it's better than what Google has).
https://github.com/M66B/NetGuard/releases

> If you get the APK from elsewhere,
> it's up to you to know what the app's manifest declares for compatible
> devices.

No. You don't understand the question.
You need to first understand EVERY app saves an APK.
Every single one.

It doesn't matter WHERE you get the app from.
The APK is saved.

The question is what is INSIDE that APK.
But you can't answer that until you know that the APK is already there.

> There are many APK manager apps available; for example:

Mostly I get my apps from Github, F-Droid, SourceForge, etc.

Rarely do I get them from the myriad app mirrors (simply because I don't
know enough to know which ones to trust).

Once in a while, when you want to get the last known good version of an app
like PulseSMS or NovaFree Launcher, you have to resort to apk mirrors.

> https://play.google.com/store/apps/details?id=com.javiersantos.mlmanager
> (There is a payware version of this app, but both freeware and payware
> app pages give almost no info on the apps, like what the paid Pro
> version gives over the free version, and neither does the dev's site.
> So, I have no idea how this author lets you "share" an APK.)

All those APK "extractors" do, as far as I'm aware, is they do a "robocopy"
(which I'm sure you're familiar with on Windows), which is just a more
intelligent copy that knows how to copy the previously saved APKs.

They don't actually "extract" anything (as far as I know).
They just copy.

You can do the copy yourself.
But then you have to find all the APKs.

These tools find them for you - much like robocopy does for Windows.

> You could, for example, get an Android update that prevents some
> previously installed apps from running, because the update, especially
> if major, can result in old features getting lost in the OS update.
> Besides a minimum Android version required by an app, there may also be
> a maximum Android version for an app. With changes in the feature set
> for Android versions, your already installed apps may not run, or some
> of their features are unusable, when you upgrade the OS.

The question remains unanswered - but I suspect the APK saved is just the
architecture specific APK - but I don't know that for a fact yet.

Nor do I know how to tell just by looking at an APK if it's the full
installer for all architectures - or only an installer for one arch.

That's why I asked the question.

[VanguardLH]

Incubus <u953...@gmail.com> wrote:

> VanguardLH <V...@nguard.LH> wrote:
>
>> Most NNTP clients can search by MID to find a post. No need to
>> involve Google Groups.
>
> You don't seem to understand the value inherent in a normal search
> engine:
> http://groups.google.com/g/comp.mobile.android

I don't need to search when I'm already visiting the newsgroup. You
don't seem to understand NNTP clients can search by MID. In fact, your
thread is just one step away from micky's, so just giving the Subject
would've been easy to find micky's thread.

> While that's probably correct, the problem with the message id is that
> you have to know the message id, which a search on the Internet
> doesn't always provide (and certainly Google Groups' searches no
> longer provide headers).

Just the opposite. If you see an article in your NNTP client, you
*always* have its MID header. By contrast, Google removed the ability
to look at headers of Usenet posts, so you cannot see the MID for an
article peered to Google Groups.

micky's thread is right here in this newsgroup, the same one you visited
to see his thread, and the same one we can see in any NNTP client.

> The advantage of the Google Groups Usenet search is that it's dejanews.

It *was* Deja News. Google has incrementally destroyed that Usenet
archive. Many search directives are gone that allowed narrow searches.
They eventually even got rid of the Advanced Search web page that had a
few remnant of the directives. Now search at Google Groups will mix
together Usenet articles with articles in their web-based forums.

> You don't need to use a Howard Knight web site to find an article by
> MID.
> http://al.howardknight.net/

That's one way, but more work than just using your NNTP client (slrn) to
see the headers of an article to get is MID header. Doesn't slrn let
you see the complete article (headers, blank delimiter line, and body)?

slrn doesn't search on a MID value? slrn won't show you the raw message
to get the MID value?

> Nor do you need to learn how each newsreader does a search by keyword.
> You simply search normally using groups.google.com/g/name.of.the.newsgroup

Which is a greedy search to include lots of hits on nothing of interest
to you. Google's search sucks.

>> The APK (Android Package Kit, aka installer file) is only needed for
>> distribution and installation as it is the compressed archive (ZIP) into
>> which the installation files are stored. Once installed, the APK is
>> superfluous, and a waste of space.
>
> Ask Andy Burns about that APK. It's stored on the Android phone.
> For _every_ app that exists on the Android phone.

Okay, but I wasn't sure if "never deletes the APK for any installed app"
meant the APK never gets deleted. Uninstalling an installed app should
eradicate the APK, too.

Leaving the APK file on the phone after the installation has completed
allows for subsequent re-installation. No need to download it again.
Might no longer be at the distributor (e.g., play.google.com). When you
download an .msi file to Windows to install a program, the .msi file
doesn't disappear unless you delete it after the installation. Since
APKs are Zip files (JAR files are Zip files), they are compressed.
Since apps are small, the APK files are also small.

I see your point of grabbing the APK file from one phone to use it to
install the app on another phone, but are you sure the other phone
matches the first phone in memory, CPU, hardware features, Android
version (where APIs can change), and so on? There are caveats to simply
copying the APK file to another device.

> It's a 1:1 relationship.
> 1. App is installed
> 2. APK is saved

1. APK gets downloaded (saved) to your phone.
2. App is extracted from APK.
3. APK /remains/ on your phone.

> If the app is installed, there is an APK for that app which is also saved.
> The only question is what is inside that APK.
> a. Is it the full installer for every architecture?
> b. Or is it the minor installer for just the one architecture?

You'd have to read the manifest file in the APK that also gets copied to
where the app gets installed. For old apps that existed at the
distributor before AAB showed up in 2018, APKs are still used. After
that, it was up to the app author to decide whether to provide a global
APK to cover several platforms, or upload an AAB file to the distributor
to let the distributor optimize the APK it delivers to your phone.

No matter how you got the APK, there is no guarantee it will work on
every phone brand and model, and across a huge range of Android
versions. If the source and target platforms are [highly] similar in
hardware and OS, an APK copy should work. If you are, for example,
trying to copy the APK for an app that requires Android 8 at a minimum,
and you copy the APK from your Android 8+ phone to an Android 4.4 phone,
very likely there will be APIs missing in the target Android, and also
probably hardware in the old phone that the new phone has.

>> The APK contains all the files an
>> app needs to function: all code (.dex files), certificates, assets,
>> resources, and manifest file. The installed app does not use the APK.
>> The APK must have all the files necessary to run the app.
>
> Yes. But. You don't appear to understand the question, mainly because
> you're guessing (assuming) that the APK is NOT saved for every app.

Not what I said. I said the APK can be deleted. That could be when you
uninstall the app (I always force stop, clear cache, and clear storage
before uninstalling), or by using a file manager. If micky already
uninstalled an app, its APK won't be on his phone to transfer elsewhere.
Seems micky still has the old app on his old phone (micky is always
short on details, like the Android versions on his old and new phones),
so the APK is still on his old phone (provided he didn't use a file
manager to delete the APK files, or a cleanup tool to get rid of
superflous files, like APKs).

Seems odd an "app" would consist of only resources (sound files) in its
APK file. Micky didn't know the name of the app, plus play.google.com
is issuing a 500 error right now, so I cannot hunt around on his
possible app name. Oop, the site just came back (after I repeatedly
retried to connect for several minutes).

https://play.google.com/store/apps/details?id=com.andromo.dev493095.app569352

The app title matches on what micky thought it was. I followed the
instructions at:

https://www.wikihow.com/Download-an-APK-File-from-the-Google-Play-Store

to get a copy of the APK for that app. Basically after finding the app
page at the Play Store, I copied that URL to:

https://apps.evozi.com/apk-downloader

Once that site got the APK, it provides a download link to retrieve it
from their site. There are probably apps that will grab the APK for an
app listed at the Play Store, but I'm not interested in trialing them.
That gave me the com.andromo.dev493095.app569352_1010_apps.evozi.com.apk
file to look at. It's a Zip file, so I added .zip as the extension (or
I could rename the .apk extension to .zip), and used Peazip (pretty much
the same as 7-zip) to look inside the archive file. Actually, with
Peazip, I didn't have to rename the file to have a .zip extension.
Peazip will work with the .apk archive file.

There are lot more files in the APK archive file than just the .mp3
sound files. It's an APK, so it must have a manifest file. There is a
classes.dex file (5.6 MB when unpacked), and that is code. There are
files for an ad platform (this is an adware app). I found the MP3 files
under the 'assets\Audio548561' folder. There are also XML and HTML
files inside the archive, but I had no interest to discover what they
are for. There is a bunch of compatibility data under the META-INF
folder. There is also a MANIFEST.MF file under that folder. A lot of
it is for hashes (SHA1-Digest) on the .mp3 files.

Note that micky said he couldn't find this app. I did, and using his
guess at the app name. My registered phone at the Play Store is an LG
V20, and running Android 8.0.0. The app's Play Store page says "This
app is available for your device", so it's compatible with my phone. As
typical of micky, he omitted his brand and model of phone, or if the
Play Store declared his target device was incompatible (but then he said
he couldn't find the app page).

The MANIFEST.MF file was 2851 lines long, but it all seemed to specify
the SHA1 hashes on the MP3 files. I didn't bother to investigate into
the 26 other files in the META-INF folder, 2 of which are certificates.
In the root folder of the APK archive (Zip) file is one called
AndroidManifest.xml. That has a list of permissions for the app (not
those granted, but those wanted). When I extract AndroidManifest.xml
from the archive file (10MB after extraction), and open it in a web
browser, I'm shown:

XML Parsing Error: not well-formed

XML files are supposed to be text files using tags for hierarchical
structure of content. I can see some text in the XML file using Notepad
or HxD, but it's definitely not just text in there. I found some info
at:

https://developer.android.com/guide/topics/manifest/manifest-intro

From that article, seems AndroidManifest.xml is supposed to be an XML
file, and XML files are text-based documents, so that file is fucked or
corrupted in the APK.


I didn't participate in micky's thread. Maybe you could reply to him to
give him the Play Store's URL to the app's page there, which is again:

https://play.google.com/store/apps/details?id=com.andromo.dev493095.app569352

He could use the method I did to retrieve the .apk file from the Play
Store although there might be an app to facilitate getting the APK for
an app based on the Play Store's URL for the app (someone else will have
to chime in on suggesting an APK puller app).

The app is still available at the Play Store. micky could get it off
his old phone if that app is still installed, or he can go to the app
page to retrieve the APK for that app. He could try to install that app
on his new phone unless he just wants to extract all the .mp3 files.

> That APK which is saved with _every_ app can either be
> a. A full APK for all architectures, or,
> b. A partial APK for only the one architecture (of the phone).
>
> Big difference.
> That's why the question is being asked.
>
> You can't guess at the answer.

You could retrieve the .apk file to look inside to discern for yourself
what are the compatibility contraints. I don't do Android app
development, and neither do you or micky. Might want to take this
discussion to an Adroid dev newsgroup to ask how to decipher just what
is specified inside the .apk archive file.

Since the app *is* still available at the Play Store, micky would be
better served to just installing it on his new phone than trying to copy
over an .apk file from an old phone, and hope it's kosher on his new
phone.

> It's either the full installer.
> Or it's an architecture-specific installer.
>
> The reason that matters is extracting that saved free APK is no different
> than just copying it - but if it's not the full installer - it might not
> work on the next phone that someone tries to run that extracted APK on.

Yep, and why I mentioned the distributor (Play Store) will interrogate
the device to see if an app is compatible when just an APK was uploaded
by the app author, or if the distributor delivers an optimized APK if
the app author uploaded an AAB file.

micky could hope the old app works on his new phone by copying the .apk
file to his new phone. Or he could retrieve the .apk file, and look
inside the archive file with any Zip tool to see what all those
compatibility files specify. Or, easiest, is he goes to the Play Store
to install the Extra Loud Ringtones app on his new phone.

> In short, always, if the app is installed, the APK is saved by Android.

"Saved" seems the wrong term. You can't get the app without getting the
APK file. "Saved" would be the act of downloading the app to your
phone. More accurately, after installation, the APK file is not
deleted.

> It doesn't seem like you understand that on _every_ Android phone, no
> matter _how_ you choose to obtain and install applications, the APK is
> saved.

I differ in your terminology. You say "saved", but really it was
initially downloaded. I say "not deleted" (after installation).

> The only question - which is the question inherent in this thread, is
> a. Is that saved APK a full installer? ... or ...
> b. Is that saved APK only a partial architecture-specific installer?

Since you don't know if the app author uploaded an APK file (before
Google cut them off back in 2018) or uploaded an AAB file (which has the
distributor deliver an optimized APK for the target platform). You'll
have to look inside the .apk archive file to see what you got from the
distributor (e.g., Play Store).

>> The APK is just a file.
>
> Yes. But it could be a full architecture file or only a sub variant.

No, it will be full for the target platform to which it was delivered.
If the distributor only has an APK file, that's all it can deliver, and
it might (or might not) cover multiple target devices. If the
distributor got an AAB file, it can deliver an optimized APK delivered
to the target device, but that optimized APK is still a full APK for the
target device. It may not be optimized or compatible on a different
device.

I already mentioned an app that looks at the TargetAPI for each app the
user installed (don't know about system apps, but micky isn't asking
about a system app). That would give him a clue if the old app on his
old phone is compatible with the OS, and other requisites, on his new
phone. Instead of all that, micky could just go to the app page to
install the old app on his new phone. I highly doubt micky is going to
retrieve and probe into .apk archive files. And without you doing that,
you can't tell micky if the old .apk file on his old phone will work on
his new phone. I did look into the .apk file, and didn't see anything
obvious restricting it from working on whatever micky gets for a new
phone, but I could read the AndroidManifest.xml file, and didn't bother
to review all the platform compatibility files.

> Not every app is installed by the Google Play Store, and, in fact, the
> more someone knows about Android, the fewer apps he uses from that
> repository.

Ask micky if he installs apps from anywhere else; otherwise, your point
is moot. APKmirror can deliver apps, but they're like the Play Store in
they are an app distributor, and can only deliver .apk files if that's
all they got, or could optimize the delivered APK if they got an AAB
file from the app author. Sorry, I've never installed apps from
APKmirror.com to know if they work with AAB files. What I know of
APKmirror is what they say, like:

https://www.apkmirror.com/faq/#Do_you_support_Google8217s_new_split_APKsApp_BundlesDynamic_Delivery

> Many times the app is installed directly from an APK which was
> downloaded off the Internet for example, oh, say, from GitHub or
> SourceForge.

Huh? Apps are always installed using an APK, or do you know a different
method, like manually copying the app files to a folder, and then
getting all the linkages set up for the app to work? For example, in
Windows (and probably Linux), you can just create a folder for a
program, and dump all the program files into that folder, and then
manually create shortcuts to the executable files. In fact, some
programs are designed to be portable: they don't have to be installed,
and they can be anywhere, even on removable media. Are there portable
apps for Android, so they don't consume any internal storage space?

> Have you ever heard of them? They have Android apps also.
> So does F-Droid.

And APKmirror. And APKpure. And APK Downloader (which retrieves APKs
from Google's Play Store). And Aptoide. And APKmonk. And on an on.

If you haven't noticed, Sourceforge became excrutiatingly slow as the
volume of project increased. Many SF authors moved to Github.

Sorry, I've never needed to sideload from a non-Google app repository.
I don't load my phone with tons of apps. If I can't find what I want at
the Play Store, I really am not impelled to look at other repositories.
That's me. Maybe you like getting apps from someone other than Google.
That's okay, too. As for micky, I don't recall him mentioning he goes
anywhere other than Google to get Android apps.

>> Not only may an app be Android version
>> dependent, it may also be device dependent.
>
> This is the reason for the question in the first place.

Since you are not the distributor testing the target device, and you
have no way to know if the distributor is delivering only an APK (that's
all they got from the app author) nor are you the app author that gave
the distributor an AAB file to allow optimizing APK delivery, you'll
have to do the same as I did: look inside the .apk file.

Without inspecting the delivered .apk file, and unless the old and new
phones are identical, you can't say if the .apk from an old phone will
work on a new phone. Not the answer you wanted as an easy means to
identifying compatibility, but I don't know of much else you can do. I
mentioned an app that looks at the TargetAPI of each user-installed app,
but all that does is give a clue as to the minimum Android version an
app requires, and nothing to do with hardware compatibility.

> Yes. A good one is the Muntashirakon. It's the best, in fact.
> https://github.com/MuntashirAkon/AppManager/releases
>
> And it's NOT on the Google Play Store either. But it is on F-Droid.
> https://f-droid.org/en/packages/io.github.muntashirakon.AppManager/

That could be another app tool to determine installed app compatibility.

> An example of where Google limits what an app can do when it's on there is
> https://play.google.com/store/apps/details?id=eu.faircode.netguard

I've seen that one mentioned in some online help articles. Don't
remember what I was hunting for, but that came up. The articles that I
found pointed to the Play Store app page.

> Nobody gets that app from the Google Play Store.

Why?

> They get it from outside the Google Play Store, like perhaps from here.
> https://www.netguard.me/

Even the app author's web site points to the Play Store's app page. At
the app author's web site, there is no other location mentioned to get
his app.

The payware Pro version is not listed at the Play Store. Instead you
must use the in-app purchase mechanism to get the Pro version. There is
a link to:

https://contact.faircode.eu/?product=netguardstandalone

which requires you donate to then get the Pro version. There is mention
of GitHub and F-Droid, but no links to an app project over there. I can
search on "netguard" at github.com, but I'd have to guess which of the
68 matches was this author's Android app, or drill them to hunt it down.
A search at f-droid.com produced 1 plausible hit:

https://f-droid.org/en/packages/eu.faircode.netguard/

Odd the app author who operates a web site for his Android app can't be
bothered to provide links to GitHub and F-Droid projects for his app,
but then he wants you to donate to get them although you might find them
yourself, and you pick the correct project.

> Which says to get it from here (because it's better than what Google
> has).
> https://github.com/M66B/NetGuard/releases

I couldn't find a link to the app author's GitHub project, but then I
didn't donate, especially since I have yet no impetus to use the app.
With multiple hits on a "netguard" search at GitHub, I might not have
picked the project you mention above.

>> If you get the APK from elsewhere,
>> it's up to you to know what the app's manifest declares for compatible
>> devices.
>
> No. You don't understand the question.
> You need to first understand EVERY app saves an APK.
> Every single one.

Um, the manifest and compatibility files are inside the APK. Obviously
you'd need the .apk file to look inside of it.

> It doesn't matter WHERE you get the app from.
> The APK is saved.

I differ. The APK is downloaded, and it is not deleted after
installation of the app. You get the APK, not the app.

> The question is what is INSIDE that APK.
> But you can't answer that until you know that the APK is already there.

Yep, so you have to inspect to know if the delivered .apk is "full" or
optimized. Sorry, I've come across nothing that blares a horn to
identify which got delivered to you.

>> https://play.google.com/store/apps/details?id=com.javiersantos.mlmanager
>> (There is a payware version of this app, but both freeware and payware
>> app pages give almost no info on the apps, like what the paid Pro
>> version gives over the free version, and neither does the dev's site.
>> So, I have no idea how this author lets you "share" an APK.)
>
> All those APK "extractors" do, as far as I'm aware, is they do a "robocopy"
> (which I'm sure you're familiar with on Windows), which is just a more
> intelligent copy that knows how to copy the previously saved APKs.

An APK is a JAR file, and JAR files came from Zip files, so you can use
any zip tool, like Peazip, 7-zip, etc, to look inside the archive file.

> They don't actually "extract" anything (as far as I know).
> They just copy.

You can use a zip tool to look inside the .apk file. You can drag a
file out of the .zip/.apk file into your file system to open with an
editor. Extraction is just showing the internals of the archive file,
or unzipping (extracting) it. I've not use any APK-specific extractor
tool or app, but then all I've needed is a zip tool to look inside, and
to yank out files.

> You can do the copy yourself.
> But then you have to find all the APKs.

Yeah, that's the bitch part. Plus, you'll need a file manager that
won't hide the .apk files, or the system folders in which they are
stored. I'd have to get a better Android file manager than the one
bundled in my phone which is way too throttled to be safe for uber
boobs. I thought I had Total Commander installed, but found it's no
longer on my phone. Must've done some cleanup in the past of rarely
used apps.

> Nor do I know how to tell just by looking at an APK if it's the full
> installer for all architectures - or only an installer for one arch.
>
> That's why I asked the question.

Get the .apk file for the app. Use a zip tool to look inside, or yank
out its folders and files. Now the fun begins: trying to decipher all
the info in those files, like what the manifest says (the one for the
Extra Loud Ringtones has an unreadable manifest file since, I believe,
it is supposed to be all text in XML format). The MANIFEST.MF file
merely had a list of all the MP3 files inside the archive file along
with a SHA-1 hash on each file. To determine compatibilities, I'd have
to dig into the folder with all the compatibility files. Nothing I want
to get into for an app in which I have no interest.

I've not investigated into the Compatibility Test Suite. Way beyond
what I care about regarding running apps on my phones. If I were to
develop Android apps, might be something I'd look into.

https://source.android.com/docs/compatibility/cts

[Andy Burns]

Incubus wrote:

> You don't seem to understand the value inherent in a normal search engine:
> http://groups.google.com/g/comp.mobile.android

That breaks down for usenet groups which google groups doesn't carry

uk.telecom got dropped because of credit card scammers posting from
google accounts, so the long history there is lost

alt.comp.software.thunderbird/firefox because google don't deign to add
new groups now.

[Jörg Lorenz]

Am 03.08.23 um 15:29 schrieb Andy Burns:

> Incubus wrote:
>
>> You don't seem to understand the value inherent in a normal search engine:
>> http://groups.google.com/g/comp.mobile.android
>
> That breaks down for usenet groups which google groups doesn't carry

Here posts over googlegroups are filtered unread to the Nirwana.


--
Alea iacta est