• PSA: Muntashirakon extracting vs Aurora exporting app bundles for archival reuse

    From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Thu Apr 2 01:35:08 2026
    From Newsgroup: comp.mobile.android

    PSA:
    Muntashirakon extracting vs Aurora exporting app bundles for archival reuse

    1. Aurora exports
    2. Muntashirakon extracts

    1. Exporting means you get EXACTLY what Google Play gave Aurora.
    2. Extracting means you get EXACTLY what Android installed.

    1. Aurora exports a split-APK bundle (base + config splits).
    2. Muntashirakon extracts the base.apk that Android actually installed.

    1. Aurora's export only works before its cache is cleared.
    2. Muntashirakon extract function only works when the app is installed.

    1. Aurora's cache is automatically cleared within minutes to hours
    2. Muntashirakon's extract will work as long as the app is installed

    1. In my test just now, Aurora exported a ZIP file
    2. While for the same app, Muntashirakon extracted an APK file

    1. Aurora temporarily saves in /data/data/com.aurora.store/cache/Downloads
    (but you need to be root in order to access that saved zip directly)
    2. Muntashirakon is not an installer so it doesn't save the app itself.

    Q: How does Aurora export the ZIP of a recently installed app?
    A: Use the Aurora Export button IMMEDIATELY after installing an app.
    A. In Aurora, go to Gear > Settings > Installation
    B. Turn OFF "Delete APK post-install"
    a. This keeps the zip from Google Play in Aurora's cache
    b. /data/data/com.aurora.store/cache/Downloads
    c. That cache is wiped clean periodically (controlled by Android)
    C. In Aurora, find your desired app & install it normally
    D. In Aurora, go to Downloads to select the 3dots next to that app
    You should see a popup menu with 4 items (some are grayed out)
    a. Cancel
    b. Install
    c. Export <=== this will gray itself out if you're not fast enough!
    d. Clear
    E. Save the app ZIP file anywhere you want on your Android filesystem. Voila!
    You've just exported exactly what Google Play gave to Aurora to install!

    Q: How does Muntashirakon extract the APK of a currently installed app?
    A: Use the Muntashirakon "Save APK" button if the app is still installed
    A. In Muntashirakon, search for the desired app by name
    B. In Muntashirakon, longpress on the app found in search results
    C. At the bottom, press "Save APK" (do not press "Backup/Restore")
    a. This always extracts to this location on internal storage
    b. /storage/emulated/0/AppManager/apks/
    c. Apps will either be extracted as an "apk" or as an "apks" file
    . apk if Android installed only base.apk
    apks if Android installed multiple split APKs
    Voila!
    You've just extracted exactly what Android installed on your device.

    1. The Aurora export is "universal" because it's what Google gave you.
    2. Muntashirakon extract is "specific" because it's what Android installed.

    1. You can not just tap on the Aurora Zip directly or on its apk contents.
    2. You can just tap on the extracted Muntashirakon base.apk but not apks

    1. The SAI app can install Aurora's ZIP directly.
    2. The SAI app can install Muntashirakon's base.apk directly.

    1. ADB can install the unzipped Aurora ZIP file indirectly.
    C:\> adb install-multiple base.apk config*.apk
    2. ADB can install the extracted Muntashirakon base APK directly.
    C:\> adb install "/storage/emulated/0/AppManager/apks/appname.apk"
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Thu Apr 2 17:03:23 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia wrote:
    1. Aurora temporarily saves in /data/data/com.aurora.store/cache/Downloads
    (but you need to be root in order to access that saved zip directly)

    Does anyone know WHY or HOW Android decides to clear Aurora's cache?
    /data/data/com.aurora.store/cache/Downloads/com.package.zip

    I asked that question, just now, in XDA Developers Forum, but maybe someone
    on this Android newsgroups understands how we can change that timing?

    Q: How can we increase the time Auroa keeps the Google Play ZIP in cache?
    <https://xdaforums.com/t/app-6-0-aurora-store-open-source-google-play-client.3739733/post-90545202>

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Jeff Layman@Jeff@invalid.invalid to comp.mobile.android on Sat Apr 4 08:17:38 2026
    From Newsgroup: comp.mobile.android

    On 02/04/2026 22:03, Maria Sophia wrote:
    Maria Sophia wrote:
    1. Aurora temporarily saves in /data/data/com.aurora.store/cache/Downloads >> (but you need to be root in order to access that saved zip directly)

    Does anyone know WHY or HOW Android decides to clear Aurora's cache?
    /data/data/com.aurora.store/cache/Downloads/com.package.zip

    I asked that question, just now, in XDA Developers Forum, but maybe someone on this Android newsgroups understands how we can change that timing?

    Q: How can we increase the time Auroa keeps the Google Play ZIP in cache?
    <https://xdaforums.com/t/app-6-0-aurora-store-open-source-google-play-client.3739733/post-90545202>

    It's maybe somewhat of a side issue, but I see from that post "Like most people, I've always saved all my APKs (at the time I install them) so
    that I can re-install the EXACT subversions whenever I factory reset or
    set up a new device."

    Perhaps I'm mistaken, but I doubt that most Android users would keep
    APKs from apps they'd uninstalled. I understand that you do a /lot/ of testing, and might keep various apps to compare. I don't, however,
    understand why Android not only does this as default, but makes it
    almost impossible to delete and perhaps even see these APKs as they're
    in an inaccessible folder. With Windows and Linux (I don't know about
    Apple), if you try something and don't like it you uninstall it and it's
    gone. Well, perhaps there are some bits still hanging around, but most
    of what was installed will have gone.

    With Android, the dross just builds up consuming memory. I'm not even
    sure if you can uninstall the APKs via adb. It might be phone-specific
    and depend on whether or not it's rootable (or perhaps via Shizuku?).
    --
    Jeff
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Sat Apr 4 16:27:47 2026
    From Newsgroup: comp.mobile.android

    Jeff Layman wrote:
    Q: How can we increase the time Auroa keeps the Google Play ZIP in cache?
    <https://xdaforums.com/t/app-6-0-aurora-store-open-source-google-play-client.3739733/post-90545202>

    It's maybe somewhat of a side issue, but I see from that post "Like most people, I've always saved all my APKs (at the time I install them) so
    that I can re-install the EXACT subversions whenever I factory reset or
    set up a new device."

    Perhaps I'm mistaken, but I doubt that most Android users would keep
    APKs from apps they'd uninstalled. I understand that you do a /lot/ of testing, and might keep various apps to compare. I don't, however, understand why Android not only does this as default, but makes it
    almost impossible to delete and perhaps even see these APKs as they're
    in an inaccessible folder. With Windows and Linux (I don't know about Apple), if you try something and don't like it you uninstall it and it's gone. Well, perhaps there are some bits still hanging around, but most
    of what was installed will have gone.

    With Android, the dross just builds up consuming memory. I'm not even
    sure if you can uninstall the APKs via adb. It might be phone-specific
    and depend on whether or not it's rootable (or perhaps via Shizuku?).

    Hi Jeff,

    It's good to hear from you, especially as I know you (and Andy) picked up Muntashirakon after I had recommended it as the best app manager out there.

    You're bringing up a *lot* of complex issues, that almost nobody on Android understands, so we can go over them 1 by 1 as they're all valid concerns.

    Aurora used to save Play Store APK bundles in public storage, but Android
    11 made Scoped Storage mandatory. That means Aurora can no longer write
    APKs anywhere except to its own private sandbox, which is located at
    /data/data/com.aurora.store/cache/Downloads/{com.package.zip}

    Unless rooted, none of us can access that zip file, and worse, Android
    treats that cache as temporary and clears it automatically, which is why
    the ZIP disappears unless we export the zip file almost immediately.

    Muntashirakon works differently because it extracts the APKs that Android already installed, and the user explicitly chooses where to save them.

    Which brings us to your points, which I'll take in series as you said 'em.

    Q: Do most users save all their installers so they can re-install later?
    A: I've always done so on every platform [except iOS ('cuz you can't)].
    But I also install from APK repos using Windows web browsers.
    And I extract APKs off of all my phones to keep in that archive.
    The actual archive is kept on a Windows USB drive, not on Android.

    You mention specifically people keeping APKs for apps they've expressly uninstalled, and that is probably true that they wouldn't want them.

    But because we tend to save the APK at the moment we install the app, we
    would have to go back to our archives (which are usually stored on hard
    drives) and delete that saved APK later, which could be minutes, hours,
    months or years later, when we decide to uninstall that particular app.

    I disagree with you on some points but agree on others when you say Android "makes it almost impossible to delete and perhaps even see these APKs as they're in an inaccessible folder", as some of that is true but some not.
    1. Android forced Aurora to save the APK in cache but that cache is easy
    to access if we're rooted (but impossible to access if not rooted).
    2. But if you're fast enough, you can EXPORT out of Aurora, which was my
    revelation for this PSA! But you have to be fast. Real fast. Minutes.

    1. Muntashirakon, on the other hand, always has access to the base.apk
    (plus splits) that Android actually installed on your system.
    2. Muntashirakon can EXTRACT those base APKs (as can adb) any time
    as long as the app is still installed on your system.
    3. This is because Android never deletes the APK of any installed app.
    (Once you uninstall the app, then Android deletes that base.apk).

    I think I need to clarify this sentence you said of "With Windows and Linux
    (I don't know about Apple), if you try something and don't like it you uninstall it and it's gone", this is also true of Android.

    The only way Android is different is that Android always saves the base APK (and now splits) if the app is installed. All other platforms don't
    necessarily save the installer, although on Windows, if you install using
    an installer, that installer usually isn't deleted automatically either.

    I agree it's confusing but once you know it, it starts to make sense.
    --
    On Usenet, experience is meant to be passed along, not hoarded.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Jeff Layman@Jeff@invalid.invalid to comp.mobile.android on Mon Apr 6 08:57:19 2026
    From Newsgroup: comp.mobile.android

    On 04/04/2026 21:27, Maria Sophia wrote:
    Jeff Layman wrote:
    Q: How can we increase the time Auroa keeps the Google Play ZIP in cache? >>> <https://xdaforums.com/t/app-6-0-aurora-store-open-source-google-play-client.3739733/post-90545202>

    It's maybe somewhat of a side issue, but I see from that post "Like most
    people, I've always saved all my APKs (at the time I install them) so
    that I can re-install the EXACT subversions whenever I factory reset or
    set up a new device."

    Perhaps I'm mistaken, but I doubt that most Android users would keep
    APKs from apps they'd uninstalled. I understand that you do a /lot/ of
    testing, and might keep various apps to compare. I don't, however,
    understand why Android not only does this as default, but makes it
    almost impossible to delete and perhaps even see these APKs as they're
    in an inaccessible folder. With Windows and Linux (I don't know about
    Apple), if you try something and don't like it you uninstall it and it's
    gone. Well, perhaps there are some bits still hanging around, but most
    of what was installed will have gone.

    With Android, the dross just builds up consuming memory. I'm not even
    sure if you can uninstall the APKs via adb. It might be phone-specific
    and depend on whether or not it's rootable (or perhaps via Shizuku?).

    Hi Jeff,

    It's good to hear from you, especially as I know you (and Andy) picked up Muntashirakon after I had recommended it as the best app manager out there.

    You're bringing up a *lot* of complex issues, that almost nobody on Android understands, so we can go over them 1 by 1 as they're all valid concerns.

    Aurora used to save Play Store APK bundles in public storage, but Android
    11 made Scoped Storage mandatory. That means Aurora can no longer write
    APKs anywhere except to its own private sandbox, which is located at
    /data/data/com.aurora.store/cache/Downloads/{com.package.zip}

    Unless rooted, none of us can access that zip file, and worse, Android
    treats that cache as temporary and clears it automatically, which is why
    the ZIP disappears unless we export the zip file almost immediately.

    Muntashirakon works differently because it extracts the APKs that Android already installed, and the user explicitly chooses where to save them.

    Which brings us to your points, which I'll take in series as you said 'em.

    Q: Do most users save all their installers so they can re-install later?
    A: I've always done so on every platform [except iOS ('cuz you can't)].
    But I also install from APK repos using Windows web browsers.
    And I extract APKs off of all my phones to keep in that archive.
    The actual archive is kept on a Windows USB drive, not on Android.

    You mention specifically people keeping APKs for apps they've expressly uninstalled, and that is probably true that they wouldn't want them.

    But because we tend to save the APK at the moment we install the app, we would have to go back to our archives (which are usually stored on hard drives) and delete that saved APK later, which could be minutes, hours, months or years later, when we decide to uninstall that particular app.

    I disagree with you on some points but agree on others when you say Android "makes it almost impossible to delete and perhaps even see these APKs as they're in an inaccessible folder", as some of that is true but some not.
    1. Android forced Aurora to save the APK in cache but that cache is easy
    to access if we're rooted (but impossible to access if not rooted).
    2. But if you're fast enough, you can EXPORT out of Aurora, which was my
    revelation for this PSA! But you have to be fast. Real fast. Minutes.

    1. Muntashirakon, on the other hand, always has access to the base.apk
    (plus splits) that Android actually installed on your system.
    2. Muntashirakon can EXTRACT those base APKs (as can adb) any time
    as long as the app is still installed on your system.
    3. This is because Android never deletes the APK of any installed app.
    (Once you uninstall the app, then Android deletes that base.apk).

    I think I need to clarify this sentence you said of "With Windows and Linux (I don't know about Apple), if you try something and don't like it you uninstall it and it's gone", this is also true of Android.

    The only way Android is different is that Android always saves the base APK (and now splits) if the app is installed. All other platforms don't necessarily save the installer, although on Windows, if you install using
    an installer, that installer usually isn't deleted automatically either.

    I agree it's confusing but once you know it, it starts to make sense.

    Just for clarity, what I was talking about was getting apps from the
    Play Store and installing them from that on an unrooted phone, as that's
    what the majority of Android phone users would do. I now understand that Aurora and Muntashirakon deal with installation in other ways (I'd often wondered why Muntashirakon pops up a message about using that to install
    an app rather than the Android OS installer, so you've explained that!).

    I think I was getting at least partially confused by what is meant by
    Android /saving/ APKs. I thought that this was a /permanent/ saving of
    any APK which had been downloaded when an app was tried for the first
    time. From what I now understand Android saves the APK of /any/ app
    which has been installed but /not/ uninstalled, even if it is never
    used. If it is uninstalled, then Android does delete the APK from its
    "hidden" folder as noted in your point 3 above.

    As that folder is hidden, though, how could you ever check what's in it
    and if it had been deleted (from an unrooted phone)? Do I assume that
    when an app is updated the APK in that hidden folder is updated in some
    way too, so that only the latest version is kept?

    I haven't used Windows in over 11 years (last one was Win7), so can't
    remember what it did or even be aware that it might have changed. With
    Linux I can download, for example, a *.deb or tar.gz and install from
    that without keeping those files. I /could/ keep them for reinstallation purposes if I wished, but have never bothered as they're available in a
    repo somewhere (and have usually been updated).

    Thanks for the helpful explanation.
    --
    Jeff
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Mon Apr 6 14:20:38 2026
    From Newsgroup: comp.mobile.android

    Jeff Layman wrote:
    I agree it's confusing but once you know it, it starts to make sense.

    Just for clarity, what I was talking about was getting apps from the
    Play Store and installing them from that on an unrooted phone, as that's what the majority of Android phone users would do. I now understand that Aurora and Muntashirakon deal with installation in other ways (I'd often wondered why Muntashirakon pops up a message about using that to install
    an app rather than the Android OS installer, so you've explained that!).

    I think I was getting at least partially confused by what is meant by Android /saving/ APKs. I thought that this was a /permanent/ saving of
    any APK which had been downloaded when an app was tried for the first
    time. From what I now understand Android saves the APK of /any/ app
    which has been installed but /not/ uninstalled, even if it is never
    used. If it is uninstalled, then Android does delete the APK from its "hidden" folder as noted in your point 3 above.

    As that folder is hidden, though, how could you ever check what's in it
    and if it had been deleted (from an unrooted phone)? Do I assume that
    when an app is updated the APK in that hidden folder is updated in some
    way too, so that only the latest version is kept?

    I haven't used Windows in over 11 years (last one was Win7), so can't remember what it did or even be aware that it might have changed. With
    Linux I can download, for example, a *.deb or tar.gz and install from
    that without keeping those files. I /could/ keep them for reinstallation purposes if I wished, but have never bothered as they're available in a
    repo somewhere (and have usually been updated).

    Thanks for the helpful explanation.


    Hi Jeff,

    All good questions, where when I thought about answering you without too
    many words, I realized all these years I've accidentally led you astray.

    I love you're asking questions because it shows you're thinking, and absorbing, and even more importantly, you're forcing me to clarify things!

    In Windows, if we install, oh, say, Irfanview.msi, it creates irfanview.exe but in Android, if we install package.apk, it just *copies* package.apk.

    The APK is the app.
    The APK is the executable.

    So it doesn't waste space.
    The downloaded APK is the actual program.

    Which answers your "update" question also, because when an app is updated,
    (or even downgraded, which Muntashirakon's app installer can do), the
    existing APK is replaced, so there is only one APK of any given name.

    And to answer your question about checking for it, adb finds it easily.
    adb shell pm path com.package.name
    If it's a monolithic APK, then you get one line output, such as:
    package:/data/app/~~[random]/com.package.name-[string]/base.apk
    Otherwise you'll get multiple lines, one for each entity:
    package:/data/app/~~[random]/com.package.name-[string]/base.apk
    package:/data/app/~~[random]/com.package.name-[string]/split_config.arm64_v8a.apk
    package:/data/app/~~[random]/com.package.name-[string]/split_config.en.apk
    package:/data/app/~~[random]/com.package.name-[string]/split_config.xxhdpi.ap k

    As for Muntashirakon App Manager also being an installer, yes, it is registered to open an APK that you tap on, so it's one of your choices.

    The Muntashirakon installer does fancy things, but mostly if your rooted. Otherwise, I don't know if it is any better than the package installer.

    As for Linux, when you run a .deb, it's essentially a script that says
    "Take this binary and put it in /usr/bin/."
    "Take these icons and put them in /usr/share/icons/."
    "Take these libraries and put them in /lib/."
    It's the same with any Windows msi installer, which is an unpackager.

    Android doesn't scatter files. It uses a Sandboxed Architecture.
    When you install an APK, you're really just copying that APK.

    Android creates a spot for that app & just drops the APK inside.
    It's kind of like when you download a portable app for Windows.

    The APK is the executable.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Mon Apr 6 15:15:18 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia wrote:
    The APK is the executable.

    Aurora's output is even better when we use some of its tricks!

    Google creates two types of files for developers:

    1. The App Bundle (.aab):
    This is the master file on Google's server.
    Google uses this to "trim" & create the custom Split APKs

    2. The Universal APK:
    Some developers still provide a single, massive APK that contains
    everything for every device.

    If an app is a "Universal APK," both Aurora & Muntashirakon will give us
    the same thing. But if it's a "Bundle," Google Play will always trim it.

    When we use the official Google Play Store app, it automatically sends our device's exact fingerprint (Model, Screen Density, CPU architecture) to
    Google. Google then sends back only the slices that fit our phone.

    Muntashirakon (MAM) can only extract what is already on our disk.

    If Google Play already trimmed the app to fit our 720p screen, MAM can't "invent" the 4K textures out of thin air. It extracts the "skinny" version because that's all that exists in our /data/app/ folder.

    But there's a trick...

    We can tell Aurora to pretend our cheap phone is a Pixel 8 Pro or a Samsung Ultra Tablet.

    If we spoof a high-end device and then "Export" the ZIP, we are getting the high-res assets and advanced CPU slices that Google would have otherwise
    hidden from our cheap phone.

    By spoofing a high-end device in Aurora, we're grabbing a bundle that
    contains the "Ultra" assets. When we subsequently archive that ZIP, we have
    a version of the app that can scale down to any phone, whereas a version extracted from a cheap phone can never scale up.

    I've never done this trick myself, but it highlights the difference between what Aurora exports versus what Muntashirakon extracts.

    Apparently if we use Aurora to spoof a "beast" device and install those high-end APKs, Muntashirakon will then extract exactly those high-end APKs.

    It's confusingly simple...
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Mon Apr 6 23:50:53 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia wrote:
    Apparently if we use Aurora to spoof a "beast" device and install those high-end APKs, Muntashirakon will then extract exactly those high-end APKs.


    Some rules for spoofing Aurora to extract a superset APK bundle.
    a. config.xxxhdpi (The high-res graphics we want).
    b. config.arm64_v8a (The CPU instructions).
    c. config.en (or whatever our primary language is).
    d. base.apk (the master APK)

    If we spoof an arm64-v8a ABI but our actual phone is armeabi-v7a,
    the app won't even parse, so the spoof CPU architecture has to match.

    Android can downscale xxxhdpi assets to a lower-res screen (though it might
    use more RAM), so we'd spoof the highest DPI (Graphics) possible.

    API Level strategy is to aim high but with caution if the app has a minSdkVersion that is higher than your current phone.

    A minor worry that might trip us up is Dynamic Delivery. Some modern apps
    don't include everything in the initial bundle. They download "Feature
    Modules" on-demand while we use the app. But that happens either way.

    Overall:
    a. Never spoof a higher ABI than our hardware actually supports.
    b. Spoofing higher DPI is generally safe.
    c. Spoof API as high as we feel safe doing (but test it first).

    For example, for my Samsung Galaxy A32-5G
    a. CPU ABI: arm64-v8a
    b. Secondary ABI: armeabi-v7a (for backward-compatibility apps)
    c. Screen density: ~450-500 dpi depending on variant
    Play treats it as xxhdpi
    d. Android version: Usually Android 13 (One UI 5.x) on current updates
    e. Features: NFC (varies by region), 5G, fingerprint, etc.

    A good spoof for my MediaTek Dimensity 720 native 64-bit chip might be:
    a. ABI: arm64-v8a
    b. DPI: xxxhdpi
    c. Android version: 14 (15 might work but be wary of 6KB Page Size support
    d. Device model: Pixel 7 Pro or Galaxy S23
    e. Locale: en_US
    f. Features: (probably best to leave at the defaults)

    Good spoofs for me therefore, might be:
    a. Pixel 7 Pro
    b. Galaxy S22 Ultra (has the advantage of allowing 32-bit apps too)
    c. Galaxy S23

    The tentative flow, as I'm thinking about this, would be:
    0. Set APK to not delete /data/data/com.aurora.store/files/Download/.
    1. Spoof {Pixel 7 Pro, Galaxy S22 Ultra, Galaxy S23}
    2. Install into /data/app/<package.name>-<randomSuffix>/
    3. Test (e.g., view it in Muntashirakon App Manager for issues)
    4. Export (from Aurora's cache, but do it before cache cleaning)
    (e.g., After an Aurora Export, open the ZIP and look for
    config.xxxhdpi.apk which would mean that the setup worked)
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Jeff Layman@Jeff@invalid.invalid to comp.mobile.android on Wed Apr 8 09:26:07 2026
    From Newsgroup: comp.mobile.android

    On 06/04/2026 19:20, Maria Sophia wrote:
    Jeff Layman wrote:
    I agree it's confusing but once you know it, it starts to make sense.

    Just for clarity, what I was talking about was getting apps from the
    Play Store and installing them from that on an unrooted phone, as that's
    what the majority of Android phone users would do. I now understand that
    Aurora and Muntashirakon deal with installation in other ways (I'd often
    wondered why Muntashirakon pops up a message about using that to install
    an app rather than the Android OS installer, so you've explained that!).

    I think I was getting at least partially confused by what is meant by
    Android /saving/ APKs. I thought that this was a /permanent/ saving of
    any APK which had been downloaded when an app was tried for the first
    time. From what I now understand Android saves the APK of /any/ app
    which has been installed but /not/ uninstalled, even if it is never
    used. If it is uninstalled, then Android does delete the APK from its
    "hidden" folder as noted in your point 3 above.

    As that folder is hidden, though, how could you ever check what's in it
    and if it had been deleted (from an unrooted phone)? Do I assume that
    when an app is updated the APK in that hidden folder is updated in some
    way too, so that only the latest version is kept?

    I haven't used Windows in over 11 years (last one was Win7), so can't
    remember what it did or even be aware that it might have changed. With
    Linux I can download, for example, a *.deb or tar.gz and install from
    that without keeping those files. I /could/ keep them for reinstallation
    purposes if I wished, but have never bothered as they're available in a
    repo somewhere (and have usually been updated).

    Thanks for the helpful explanation.


    Hi Jeff,

    All good questions, where when I thought about answering you without too
    many words, I realized all these years I've accidentally led you astray.

    I love you're asking questions because it shows you're thinking, and absorbing, and even more importantly, you're forcing me to clarify things!

    In Windows, if we install, oh, say, Irfanview.msi, it creates irfanview.exe but in Android, if we install package.apk, it just *copies* package.apk.

    The APK is the app.
    The APK is the executable.

    I'm more than a bit confused by that!

    According to <https://en.wikipedia.org/wiki/Apk_(file_format)#Package_contents>, an
    APK file is equivalent to a zip file. It contains several files and
    folders, including lib files (with compiled code for various processors)
    and classes.dex files (with an updated format) intended to be used by
    Android Runtime.

    And according to <https://www.browserstack.com/guide/what-is-an-apk-file>:

    * When an APK is installed, Android unpacks the contents, extracts
    necessary files, and places them in the appropriate system folders.
    * The Android OS then reads the app’s manifest to understand its
    structure, permissions, and components to run the app smoothly.

    Or are you saying that it's all done "automatically" from an APK when an
    icon on the desktop is clicked?

    So it doesn't waste space.
    The downloaded APK is the actual program.

    Which answers your "update" question also, because when an app is updated, (or even downgraded, which Muntashirakon's app installer can do), the existing APK is replaced, so there is only one APK of any given name.

    And to answer your question about checking for it, adb finds it easily.
    C:\> adb shell pm path com.package.name
    If it's a monolithic APK, then you get one line output, such as:
    package:/data/app/~~[random]/com.package.name-[string]/base.apk
    Otherwise you'll get multiple lines, one for each entity:
    package:/data/app/~~[random]/com.package.name-[string]/base.apk
    package:/data/app/~~[random]/com.package.name-[string]/split_config.arm64_v8a.apk
    package:/data/app/~~[random]/com.package.name-[string]/split_config.en.apk
    package:/data/app/~~[random]/com.package.name-[string]/split_config.xxhdpi.ap k

    As for Muntashirakon App Manager also being an installer, yes, it is registered to open an APK that you tap on, so it's one of your choices.

    The Muntashirakon installer does fancy things, but mostly if your rooted. Otherwise, I don't know if it is any better than the package installer.

    As for Linux, when you run a .deb, it's essentially a script that says
    "Take this binary and put it in /usr/bin/."
    "Take these icons and put them in /usr/share/icons/."
    "Take these libraries and put them in /lib/."
    It's the same with any Windows msi installer, which is an unpackager.

    Android doesn't scatter files. It uses a Sandboxed Architecture.
    When you install an APK, you're really just copying that APK.

    Android creates a spot for that app & just drops the APK inside.
    It's kind of like when you download a portable app for Windows.

    The APK is the executable.
    --
    Jeff
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Wed Apr 8 15:28:55 2026
    From Newsgroup: comp.mobile.android

    Jeff Layman wrote:
    I'm more than a bit confused by that!

    According to <https://en.wikipedia.org/wiki/Apk_(file_format)#Package_contents>, an
    APK file is equivalent to a zip file. It contains several files and
    folders, including lib files (with compiled code for various processors)
    and classes.dex files (with an updated format) intended to be used by Android Runtime.

    And according to <https://www.browserstack.com/guide/what-is-an-apk-file>:

    * When an APK is installed, Android unpacks the contents, extracts
    necessary files, and places them in the appropriate system folders.
    * The Android OS then reads the app's manifest to understand its
    structure, permissions, and components to run the app smoothly.

    Or are you saying that it's all done "automatically" from an APK when an icon on the desktop is clicked?

    All good queswtions. I'm glad we can work this out. Together.

    Bear in mind that I'm confused also. So let's work this out together.
    Anything I've said or will say, can be wrong, so I admit that up front.

    This is how I think about it.

    Did you ever download an exe for Windows, and when you ran it, it unpacked something and ended up installing a different exe in the Program Files dir?

    They're both exe's right.

    But one is the installer executable.
    The other exe is the installed executable.

    So the very nature of an exe is to be confusing.
    Q: Is an exe the installer? Answer = yes.
    Q: Is an exe the installed executable? Answer = yes.

    In the Android world, the "unpacked/installed" version of the code is
    stored in files called .odex or .vdex (the "installed executable").

    However, unlike Windows, Android doesn't scatter the icons and
    resources into separate folders. It leaves them inside the APK.

    So, while the APK is a "zip" (the container), it remains on the
    system because the OS needs to pull images and layouts out of it
    every time you run the app. If you delete the APK, the app is
    gone since "The APK is the app." It is the permanent home for
    everything that isn't the raw compiled code.

    Now you asked if "it's all done automatically".
    Well... um... er... yes. And, um, er... no.

    Here's the fun part. Optimization.

    1. Google Play sends our device a bundle of apks for most apps.
    a. base.apk,
    b. split_config.arm64_v8a.apk,
    c. split_config.xxhdpi.apk,
    d. split_config.en.apk

    2. The package manager puts all that apk 'stuff' into one folder
    /data/app/~~[random_string]/com.example.app-[string]/

    3. At some point after that, dex2oat reads classes.dex inside
    the base.apk and compiles that into machine code in a oat
    subfolder containing base.odex & base.vdex (for verification).

    4. Only after that compile step is the app actually "installed".

    5. When you tap the app shortcut, the base.odex is executed.

    6. But the code grabs a lot of things from the base.apk too.

    When we archive the app, we don't need the dex/vdex stuff.
    So the archive doesn't contain that pre-compiled machine code.
    The archive just contains the zip of all the apk files.

    Aurora puts all those apk files into a single zip file.
    Muntashirakon puts them into a single apks file.
    But if you rename the zip to apks, it's (almost) the same.

    Now, to your specific questions...

    You said Wikipedia said an apk is equivalent to a zip.
    It is a zip. It's just one file containing the other files.

    The Wikipedia also said that it contained "compiled code".
    That's both right and wrong.
    If it's an apk that is not yet installed, there is no compiled code.
    If it's an apk that has been extracted, there is no compiled code.

    But if it has been installed, then yes, there is compiled code.
    That compiled code is in (oh shit!). It depends.
    In Android 9 to about Android 5, that dex stuff is in the APK folder.
    /data/app/com.example.app-string/oat/arm64/base.odex

    /data/app/com.example.app-string/oat/arm64/base.vdex

    But in Android 10 and above, they're located (flat!) elsewhere
    /data/misc/profiles/cur/0/com.example.app/
    /data/dalvik-cache/[architecture]/

    Is this complicated enough yet?

    The good news is it's easy to see why in Andrloid 10 and above,
    Muntashirakon (unrooted) has zero access to those dex/vdex files.

    So it's impossible for Muntashirakon to extract them anyway. :)

    For example, they are in:
    /data/dalvik-cache/arm64/data@app@~~[RandomString]@@com.example.app-[String]@base.apk@classes.dex
    /data/dalvik-cache/arm64/data@app@~~[RandomString]@@com.example.app-[String]@base.apk@classes.vdex

    Why so long?
    Because it's flattened!
    All apps put the compiled code in the same spot!

    If you're not completely confused by now, you haven't been listening.
    :)

    In summary, the APK that is installed, *is* (most of) the application,
    with the exception that some of the base.apk's contents are pre-compiled
    and stored elsewhere (i.e., the dex/vdex files) but they're not needed for archival purposes.

    So when we archive, we only need to zip up the individual apk files.
    Whether we call that bundle a zip or an apks file is immaterial.

    Whew!
    How'd I do?

    Did I confuse you more?
    Or less?

    Let's both keep trying until we nail this down as it's not intuitive.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Wed Apr 8 15:42:38 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia wrote:
    The Wikipedia also said that it contained "compiled code".
    That's both right and wrong.
    If it's an apk that is not yet installed, there is no compiled code.
    If it's an apk that has been extracted, there is no compiled code.

    Actually, some of that is incorrect, which I noticed when double checking
    your Wikipedia link.

    The wikipedia is right, and it's wrong on "compiled code" because it
    depends on how we "define" compiled code. Sigh. Are you confused yet?

    Inside every APK (whether it is installed, extracted, or just sitting in
    our Downloads folder), there is compiled code; it's just not machine code.

    The APK contains classes.dex, which is Dalvik Bytecode, compiled from Java
    or Kotlin, but the phone CPU cannot run it directly. It's not specific.

    Once the app is installed and the Android runtime "optimizes" it, then the .odex/.vdex files are the 1's & 0's that are the machine code the CPU runs.

    Your Wikipedia link says it contains "compiled code," which is true, but
    it's a universal version (bytecode) that isn't ready for the CPU to run.

    The "Installation" process takes that Dalvic Bytecode from the base.apk
    and turns it into the "Machine Code" (.odex/.vdex) I mentioned earlier.

    Whew!
    If we're not confused, we aren't following along. :)
    --- Synchronet 3.21f-Linux NewsLink 1.2