• PSA: Script to archive working APK & APK bundles from Android to the desktop

    From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Sat Aug 1 11:10:31 2026
    From Newsgroup: comp.sys.mac.apps

    Having been on 'puters since before the PC, the one thing ingrained in my backup/restore methodology is to save all installers at installation time.

    I generally save all installers to a USB drive attached to the desktop.
    But how do you it with Android installers when Google Play deletes them?

    Especially when most of the time the device is on your LAN over Wi-Fi.
    This script will copy the APK after install to your desktop over Wi-Fi.

    I wrote it yesterday and only tested on my phone & on Windows.
    But it should work on any platform, when ported to that platform.

    The concept is what matters as this backs up & restores sans the net.
    i. You back up the installer at the time you installed the app
    (Yes Virginia, this works even if you never did a backup prior.)
    ii. Then, you copy your homescreen to any phone you want
    iii. And then you tap on the gray icons, one by one, to restore

    It's so elegant that I think others should try it too. Here's how...
    1. Install any desired set of apps on your Android phone by any method
    (Google Play, F-droid, Aurora, Github, developer home pages, etc.)
    2. Then run this script, which brings up Muntashirakon App Manager
    <https://github.com/MuntashirAkon/AppManager> (apk)
    <https://muntashir.dev/AppManager/en/> (doc)
    3. In App Manager on the phone, select the app(s) and press "Save APK".
    That will save the APK or APKs bundle to a known static folder:
    /storage/emulated/0/AppManager/apks (either name.apks or name.apk)

    Voila!
    You've now fully backed up every APK that you ever installed on the phone!

    Better still, if you save your homescreen to a backup file (about 5MB),
    then you can install everything on another phone w/o needing the Internet.

    A. You backup your home screen by pressing your launcher backup button.
    B. You restore that homescreen on any other Android phone you want.
    C. For every gray icon, you just tap it and it re-installs the app.

    Voila!
    You've now got a brilliantly efficient backup/restore strategy working!

    :: copyapk.bat
    :: Pulls APKs saved by Muntashirakon App Manager from phone to desktop
    :: -------------------------------------------------------------------
    :: v1p4 20260730 Added instructions for saving APK and split APKs files
    :: v1p3 20260730 Added a clean quit instead of typing control+C
    :: v1p2 20260730 Added choice of opening Muntashirakon App Manager
    :: v1p1 20260730 Added choice of destination directory
    :: v1p0 20260730 Original version (for use with Muntashirakon Save APK)
    :: -------------------------------------------------------------------
    @echo off
    setlocal enabledelayedexpansion

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

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

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

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

    REM ===== Default destination folder [change to your location ] =====
    set "DEST=H:\software\backup"

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

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

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

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

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

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

    REM Get file list from device
    REM Split APKs are saved as name.apks, otherwise it's name.apk
    adb shell ls "/storage/emulated/0/AppManager/apks" > filelist.txt

    set /a count=0

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

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

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

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

    echo.

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

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

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

    :: end of copyapk.bat
    --
    We should never need the Internet just to backup & restore our programs.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Sat Aug 1 18:53:38 2026
    From Newsgroup: comp.sys.mac.apps

    Lawrence DoOliveiro wrote:
    2. Then run this script, which brings up Muntashirakon App Manager
    <https://github.com/MuntashirAkon/AppManager> (apk)
    <https://muntashir.dev/AppManager/en/> (doc)

    Seems an unnecessarily complicated way of doing it.

    adb itself already has commands to list the installed packages and the locations of their .apk files, and also to copy those files back to
    your host machine.

    Hi Lawrence,

    Thank you for that point of view.

    Your perspective is critically important, since there *are* many ways.
    The question, really, is which archival method is the absolute best.

    Here is an example of pulling an APK (not a split APK) off Android:
    1. List packages installed on the device & grep one to work with
    adb shell pm list packages | findstr /i shizuku
    => package:moe.shizuku.privileged.api
    2. Show the path to its given installed package
    adb shell pm path moe.shizuku.privileged.api
    => package:/data/app/~~j2Bfj74f4DUXxNA5r8nvlQ==/moe.shizuku.privileged.api-EfgdS0yVAmbHZDgZAOOXtg==/base.apk
    3. Pull that installer into your archival repository
    adb pull /data/app/~~j2Bfj74f4DUXxNA5r8nvlQ==/moe.shizuku.privileged.api-EfgdS0yVAmbHZDgZAOOXtg==/base.apk
    => ged.api-EfgdS0yVAmbHZDgZAOOXtg==/base.apk
    /data/app/~~j2Bfj74f4DUXxNA5r8nvlQ==/moe.shizu...
    0 skipped. 3.3 MB/s (3442426 bytes in 0.986s)

    It's a bit messier, but not impossible for split APKs nowadays.
    1. List packages installed on the device & grep one to work with
    adb shell pm list packages | findstr /i caffeine
    => package:moe.zhs.caffeine
    2. Show the path to its given installed package
    adb shell pm path moe.zhs.caffeine
    => package:/data/app/~~cwkaFYPKhJ4RYsCqF9qzNA==/moe.zhs.caffeine-xFWQPgNE7sKZxciAcZsl-Q==/base.apk
    => package:/data/app/~~cwkaFYPKhJ4RYsCqF9qzNA==/moe.zhs.caffeine-xFWQPgNE7sKZxciAcZsl-Q==/split_config.arm64_v8a.apk
    => package:/data/app/~~cwkaFYPKhJ4RYsCqF9qzNA==/moe.zhs.caffeine-xFWQPgNE7sKZxciAcZsl-Q==/split_config.en.apk
    => package:/data/app/~~cwkaFYPKhJ4RYsCqF9qzNA==/moe.zhs.caffeine-xFWQPgNE7sKZxciAcZsl-Q==/split_config.es.apk
    => package:/data/app/~~cwkaFYPKhJ4RYsCqF9qzNA==/moe.zhs.caffeine-xFWQPgNE7sKZxciAcZsl-Q==/split_config.xhdpi.apk
    3. Pull that split apk bundle installer into your repository
    adb pull ... /base.apk, /split_config.arm64_v8a.apk, etc.
    4. Zip them up and call the zip file "caffeine.zip" then unzip.
    adb install-multiple ...

    This worked well on Android 4-8 (especially sans split APKs).
    But on modern Android (10-14), it runs into some problems.
    A. SELinux locks /data/app on some devices (e.g., Huawei)
    B. Some apps are locked via Play Store's session API
    C. adb sees what pm path returns but App Manager reads metadata

    Bear in mind, Muntashirakon App Manager is on most Android
    devices for a reason. It's the best app manager on the planet.

    Muntashirakon App Manager does more than adb:
    a. It reads the package metadata
    b. It identifies all splits
    c. It bundles them into a proper .apks archive
    d. It includes manifest metadata
    e. It includes signing information
    f. It includes install session metadata
    g. It includes split dependency ordering
    h. It includes ABI/screen/language splits
    i. It includes dynamic feature modules
    j. It includes hidden splits that adb does not list

    As far as I know, adb can not re-create a correct app bundle.
    So Muntashirakon's results will be more reliable than adb's.

    I wish it weren't so.
    If someone can prove me wrong, I'd love to learn from them.
    --
    Always grateful for those on Usenet who teach me what I donot yet know.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Sun Aug 2 11:05:11 2026
    From Newsgroup: comp.sys.mac.apps

    Maria Sophia wrote:
    As far as I know, adb can not re-create a correct app bundle.
    So Muntashirakon's results will be more reliable than adb's.

    I wish it weren't so.
    If someone can prove me wrong, I'd love to learn from them.

    The goal is to archive Android apps to the desktop, whether that desktop is Windows, Linux, or macOS, and to be able to restore them on any new device.
    a. Without root, for free, no ads, & over Wi-Fi on the LAN (or USB)
    b. Without ever needing anything whatsoever from the Internet
    c. Without needing the app to still exist anywhere om the net, in fact
    d. And without needing to log into any privacy-robbing mothership account Because the instant you set up any mothership account, privacy is toast.

    Of course, it's nice to also get all the data backed up to the desktop.
    And personalized settings. But later Android versions made this harder.

    If needed, I can port the copyapk script so that it works on Linux/macOS,
    but before we do that, we need to address all of Lawrence's concerns.

    Given Lawrence isn't wrong that "there must be a better way", I looked for
    an Android app archiver that actually worked given Android has drastically changed in terms of permissions in protected areas since about Android 10.

    It turns out that only Google itself can really archive apps reliable, if
    we include things like data and hidden splits and not-installed modules.

    Only Google Play Store's Play Install API (session API) sees the full AAB including dynamic features, language & density splits, instant-app modules, session metadata, signing metadata, dependencies, ABI splits, etc.

    And, it turns out, I was wrong. Lawrence was right in that adb is 100%
    reliable with splits, other than we have to re-assemble & rename ourselves.

    So the batch file "could" have used adb alone, to copy the splits & rename. Where the goal, always, is to archive on the desktop & re-install anywhere.

    In looking up Lawrence's concerns, I found SELinux also doesn't block adb.
    ADB uses the package manager, not filesystem access, so it does see /data.

    I was wrong. Lawrence is right.
    Note that I don't mind being wrong because I care only about what's right.
    But that answer doesn't change that we need to copy it back to the desktop.

    Furthermore, I found an app archiver which was already on my device because
    I was using it as a split installer (akin to Muntashirakon's installer).
    <https://github.com/Aefyr/SAI>
    <https://f-droid.org/en/packages/com.aefyr.sai.fdroid/>

    There's also NeoBackup, Swift Backup and Titanium Backup, all of which can
    back up data, but all need root to backup data, so we're only talking APKs.
    1. Neo Backup (FOSS, backs up apk & apks sans root)
    2. Swift Backup (backs up apk & apks sans root) but it may have ads
    3. Titanium Backup (venerable, requires root, old, no longer developed)

    There's also "ML Manager" on F-Droid but it seems to not handle splits.
    Neither does "APK Extractor" or "App Backup & Restore" or "AppShare".

    In summary, if we are not rooted and if we want to back up our free apps
    our devices so that we can later reinstall those apps on any other device (hardware limits taken into account), our best backup options are ...
    A. adb commands to back up and restore apps
    B. Muntashirakon App Manager backup & restore
    C. SAI backup & restore
    D. Neo Backup & restore
    E. Swift Backup & restore

    As far as I have been able to find out, those are our only five options.

    But all of them *still* need to copy the APK over to the Windows, Linux or macOS desktop, which, after all, is the topic of this thread conversation.
    --
    Interestingly, I found Android 15 introduced something called that.
    <https://support.google.com/googleplay/answer/15523443>
    Apparently it's a "partial uninstall" but it's not what we are seeking .
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Sun Aug 2 23:30:40 2026
    From Newsgroup: comp.sys.mac.apps

    Maria Sophia wrote:
    It turns out that only Google itself can really archive apps reliable, if
    we include things like data and hidden splits and not-installed modules.

    Only Google Play Store's Play Install API (session API) sees the full AAB including dynamic features, language & density splits, instant-app modules, session metadata, signing metadata, dependencies, ABI splits, etc.

    UPDATE

    I realized belatedly there are difficulties with the description above,
    because Google doesn't usually archive apps any more than Apple does.

    Both motherships literally (almost) forbid backing up the app installer
    itself, where both overwhelmingly steer users toward a brand new IPA/APK.

    This brand new IPA/APK would be found on their respective App Stores.
    But there's a catch.

    You won't get the same version you had installed on your device.
    Since you'll only get the latest version.

    Worse. Far worse, in fact, is if the app no longer exists, you lose.
    (There's a way around that for both Apple & Google, but that's an aside.)

    So, essentially, neither Apple nor Google actually back up the installer.
    They only back up the data and then they re-install the latest installer.

    The advantage, of course, of them re-installing the latest installer, especially when the new phone is different hardware from the old phone,
    is that you get the right set of select components for that new hardware.

    For Android, app data is handled by the Android backup framework.
    The app installation is handled by the Android Play Install API.
    <https://developer.android.com/identity/data/backup>

    Then there's D2D... Googleos built-in migration system inside Android.
    (And the similar Samsung Smart Switch Device-to-Device migration tool.)
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Mon Aug 3 00:15:30 2026
    From Newsgroup: comp.sys.mac.apps

    Lawrence D'Oliveiro wrote:
    Seems an unnecessarily complicated way of doing it.

    adb itself already has commands to list the installed packages and the locations of their .apk files, and also to copy those files back to
    your host machine.

    Breakthrough!


    I found a cross-platform adb complete solution Lawrence was asking about!
    If any solution requires logging into a mothership to work, it's garbage.

    In researching Lawrence's concerns, I found this, which seems to be a
    complete adb Android backup/restore solution for MacOS, Linux, Windows.
    <https://github.com/mrrfv/open-android-backup>

    Such that, instead of adb pulling the saved installers as they are...
    base.apk
    split_config.en.apk
    split_config.arm64.apk

    We get an archive named appropriately, such as...
    com.example.app/
    com.example.app_base.apk
    com.example.app_en.apk
    com.example.app_arm64.apk

    It will also back up data, but only to the level that it has permissions.
    Note that it will back up contacts and images in addition to apps & data.

    Here is the blurb about it:
    Open Android Backup
    Formerly Linux Android Backup.

    Open Android Backup is a tiny shell script & Flutter app that makes
    securely backing up Android devices easy, without vendor lock-ins or
    using closed-source software that could put your data at risk. It's
    based on ADB but doesn't use the deprecated adb backup command. This
    project works on Windows, macOS and Linux.

    Note that full installation instructions are provided on that web page
    for macOS, Linux, and for Windows, so the list below is just a summary.

    1. For the desktop: Open_Android_Backup_v1.2.3_Bundle.zip
    <https://github.com/mrrfv/open-android-backup/releases/download/v1.2.3/Open_Android_Backup_v1.2.3_Bundle.zip>
    Name: Open_Android_Backup_v1.2.3_Bundle.zip
    Size: 24083458 bytes (22 MiB)
    SHA256: D1CA878FBCBDE68D6EB186655EF7C4D4ECE6601D60A34AAD6C871C3F271307A8
    Note that it uses WSL on Windows, so it's really a linux tool at heart.

    2. For the Android: app-arm64-v8a-release.apk
    <https://github.com/mrrfv/open-android-backup/releases/download/v1.2.3/app-arm64-v8a-release.apk>
    Name: app-arm64-v8a-release.apk
    Size: 17065561 bytes (16 MiB)
    SHA256: 4FC028EFA126FE3D9D82FD74AC36E8A559880F418D51910BB7EEF11DE1F7F889

    In summary, from my research only, this seems to be the best cross platform adb-only (it also uses fluffy) complete Android backup/restore solution.

    As always, if you can find a better solution, please advise.

    The goal is to always improve and never give up on doing what WE want.
    Not what Marketing wants us to do.
    --
    Here on Usenet each of us have decades of experience messing up our OS.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Mon Aug 3 10:34:12 2026
    From Newsgroup: comp.sys.mac.apps

    Maria Sophia wrote:
    As always, if you can find a better solution, please advise.

    The goal is to always improve and never give up on doing what WE want.
    Not what Marketing wants us to do.

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

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

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

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

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

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

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

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

    Given that, it's going to be my new backup/restore solution moving forward.
    How about you?
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Wed Aug 5 13:48:01 2026
    From Newsgroup: comp.sys.mac.apps

    UPDATE

    I just wrote this up for the UK telecom group where someone asked what Android/iOS backup mechanism most people use where the summary is useful...

    Newsgroups: uk.telecom.mobile
    Subject: Re: Backing up your mobile phone?
    Date: Wed, 5 Aug 2026 13:27:21 -0800
    Message-ID: <11509rp$4pp$1@nnrp.usenet.blueworldhosting.com>

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


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

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

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

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

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

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

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

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

    Right?

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

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

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

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

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

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

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

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

    As always, anything I say can be wrong (and probably is), so please
    fix where I err or omit so that we end up with more knowledge overall.
    --
    Usenet allows purposefully helpful people to pool their experiences.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Hank Rogers@Hank@nospam.invalid to comp.mobile.android,alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.apps on Wed Aug 5 17:24:19 2026
    From Newsgroup: comp.sys.mac.apps

    Maria Sophia wrote on 8/5/2026 4:48 PM:
    As always, anything I say can be wrong (and probably is), so please
    fix where I err or omit so that we end up with more knowledge overall.

    Better yet, wait a short while. USE that time to research and test your
    ideas before spewing them out to a bunch of newsgroups.

    You'll be in a better position to contribute in a positive manner. I
    doubt anyone will think you a fool for doing this. Think about it Mary.

    --- Synchronet 3.22a-Linux NewsLink 1.2