Incubus <
u9536612@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)