This is a simple MicroG installer. It can install MicroG and other stuff into your system partition or as a Magisk module. It supports virtually all mobile architectures (arm/64, x86/64, mips/64) and fully supports KitKat and above. It can also (mostly) support much older versions, but sync adapters and some location providers won't work. It can even uninstall itself from your device, just rename it and flash it again.
The things included in the Standard Edition zip are:
The things included in the `Standard` Edition zip are:
- Google Play store (modded for IAPs by Setialpha)
- Some Google DRM jars (From OpenGApps GitHub repo)
- Permission files for all of this
- An addon.d file to backup/restore everything on a rom flash
The things included in the AuroraServices Edition zip are:
The things included in the `AuroraServices` Edition zip are:
- AuroraServices (From Whyorean's GitLab)
- Permission files for all of this
- An addon.d file to backup/restore everything on a rom flash
@ -69,14 +69,14 @@ The maker does not support or endorse dirty flashing. It will harm you and your
How to control the zip by changing its name:
NOTE: Control by name is not possible in Magisk Manager, since it copies the zip to a cache directory and renames it install.zip. This is unavoidable behaviour.
- Add 'system' to its filename to force it to install/uninstall from system. Otherwise, it looks for Magisk, and if not found, installs to system. Obviously, if you flash it through Magisk Manager, you want to install it to Magisk. If not, you have to flash it through recovery.
- Add `system` to its filename to force it to install/uninstall from system. Otherwise, it looks for Magisk, and if not found, installs to system. Obviously, if you flash it through Magisk Manager, you want to install it to Magisk. If not, you have to flash it through recovery.
- Remember that choosing Magisk mode (which is the default if Magisk is installed already) will remove the MinMicroG package if you uninstall Magisk.
- Add 'uninstall' to its filename to uninstall it from your device, whether in Magisk mode or system mode. If you use Magisk Manager, your preffered method of uninstallation is from there.
- Add `uninstall` to its filename to uninstall it from your device, whether in Magisk mode or system mode. If you use Magisk Manager, your preffered method of uninstallation is from there.
Just rename it and flash it again for the intended effect. For example, **MinMicroG-variant-version-signed.zip** to **system-MinMicroG-variant-version-signed.zip** (and the same for uninstall).
Just rename it and flash it again for the intended effect. For example, `MinMicroG-variant-version-signed.zip` to `system-MinMicroG-variant-version-signed.zip` (and the same for uninstall).
NOTE: If you have made a system install but have Magisk installed as well, you will have to use both "system" and "uninstall" keywords in the name for an uninstall flash.
NOTE: If you have made a system install but have Magisk installed as well, you will have to use both `system` and `uninstall` keywords in the name for an uninstall flash.
The zip debloats three specific Google apps from your phone (GmsCore, GoogleServicesFramework, Phonesky and their MicroG counterparts) and 4 NLP providers when the pack contents conflicts with them. In Magisk mode, they won't be removed from system, and if you uninstall the pack, they'll come back. If you install in system, the debloated stuff will be stored in internal-storage/MinMicroG/Backup.
WARNING: This zip does not and never will debloat anything else because that is the minimum coming in MicroG's way. I have had my own share of PTSD with debloating. I believe (through instinct) that it should work even on flashes over GApped ROMs, but don't take my word for it. Debloat before you flash.
@ -88,10 +88,10 @@ If you used Magisk Manager, provide its logs.
### How do I build these packs myself?
List of hard dependencies:
- coreutils or equivalent [POSIX-compatible]
- curl (update.sh)
- jq (update.sh)
- unzip (update.sh)
- zip (build.sh)
- `curl` (update.sh)
- `jq` (update.sh)
- `unzip` (update.sh)
- `zip` (build.sh)
cd to this directory and run:
```
@ -105,18 +105,18 @@ To build all the packs and place them in the releases directory.
That's it! If it tells you that some dependency is missing, install it.
You can pass update.sh several perl-style regexes as arguments to only download specific files.
You can pass build.sh some specific pack's conf names instead of all to build only the specific packs.
You can pass `update.sh` several perl-style regexes as arguments to only download specific files.
You can pass `build.sh` some specific pack's conf names instead of all to build only the specific packs.
If you have the Java SDK and openssl tool installed, the update script will dump the signing certificates of all downloaded APKs and repo jars to resdl/util/certs. It will compare all future downloads with those certs, and in case of any signature errors or mismatches, will warn you.
If you have the Java SDK and `openssl` installed, the update script will dump the signing certificates of all downloaded APKs and repo jars to resdl/util/certs. It will compare all future downloads with those certs, and in case of any signature errors or mismatches, will warn you.
If you have aapt installed, the update script will download the permission docs from the Android website, check the priv-apps for any new privileged permissions and tell you to add them to the whitelist in res/system/etc/permissions/[package].xml files.
If you have `aapt` installed, the update script will download the permission docs from the Android website, check the priv-apps for any new privileged permissions and tell you to add them to the whitelist in res/system/etc/permissions/[package].xml files.
If you have java installed, you can automatically get the build script to sign all zips with testkeys. You will need to compile a zipsigner.jar (topjohnwu's rewrite of the AOSP version) and put it into into resdl/util. The source can be found in the Magisk repo, and a prebuilt binary [here](https://github.com/FriendlyNeighborhoodShane/MinMicroG_releases/releases/download/init/zipsigner.jar)
If you have `java` installed, you can automatically get the build script to sign all zips with testkeys. You will need to compile a zipsigner.jar (topjohnwu's rewrite of the AOSP version) and put it into into resdl/util. The source can be found in the Magisk repo, and a prebuilt binary [here](https://github.com/FriendlyNeighborhoodShane/MinMicroG_releases/releases/download/init/zipsigner.jar)
To build your own custom pack, refer to custom-pack.md in the conf directory.
Any changes made to the code should ideally be tested with test.sh, which runs the shellcheck linter program on every script.
Any changes made to the code should ideally be tested with `test.sh`, which runs the shellcheck linter program on every script.
### Credits
- Thanks to @osm0sis for the base magisk/recovery code and inspiration and guidance on the majority of the stuff in here.
Every pack is built and installed according to a config file. A config file is supposed to be a simple shell script setting some variables and functions. It's not supposed to execute any command, which is important, as it is executed by both the building process on the building device and the flashing process on the flashing device.
All the config files are named as defconf-[name].txt where [name] is the argument you'll pass to build.sh to build a pack using that config file.
The resdl-download.txt file is a special config that is read by update.sh to download all the relevant dynamic assets.
All the config files are named as defconf-[name].txt where [name] is the argument you'll pass to `build.sh` to build a pack using that config file.
The resdl-download.txt file is a special config that is read by `update.sh` to download all the relevant dynamic assets.
The rest of the files here are code snippets you might find useful to put in install actions.
For making your own pack and config file, check custom-pack.md
## Variables in defconf files
- variant: The name that will be in the filename of the released zip as well as will be shown on installation. It does not have to be related to the name of the defconf file (for example the defconf-unlp.txt file has variant "Backend" and creates the MinMicroG-Backend-*-*.zip package). Any string without whitespace will do.
- ver: The version number of the package, which is shown in the release filename and during installation. It can be anything except whitespace, but for convenience is integers along with decimals.
- verc: The version code for the package. It's only really used in Magisk installations's mod.prop, where Magisk compares it to decide if a version of the module is newer than the installed version. It strictly has to be an integer.
- date: The date of releasing the specific pack version, shown on installation.
- minsdk: The minimum Android SDK version the pack supports fully. It'll still install below that, but will show a warning to the user.
- modprop: The variable containing the entirety of Magisk's mod.prop, which will appear in your installed modules. Nothing really important here except verc, which is described above, and id, which has to be the same as modname variable from update-binary.
- stuff, stuff_arch, stuff_sdk, stuff_arch_sdk: Stuff variables are really space/tab-separated lists of all the objects (Relative to the root of the zip during flashing, or relative to either res or resdl directories in the build process) that are installed to be installed to device. in every device, regardless of architecture or SDK version. It is going to be put through a for loop, so no whitespace is to be used in a single entry. Luckily, android system files aren't supposed to have spaces in their names/paths. For files in stuff, the file with that path is grabbed directly from res or resdl (in ascending priority), while for the other arrays, the files are grabbed from $(dirname [path])/-*-/$(basename [path]) (further clarification in build-your-pack.md).
- stuff_other, stuff_old: Just lists of stuff from other packs and stuff that used to be in any of the packs that I made for organisation. They have no purpose other than to be merged in stuff_uninstall.
- stuff_uninstall: Everything in this list is removed from system during a system installation and uninstallation. Should include everything in the pack, along with anything that used to be in it and anything that might be from alternative conflicting packs.
- stuff_debloat: Anything not from these packs that might conflict with it. For example GApps, other location providers, etc. They are removed (and backed up) during a system install and pseudo-debloated during a Magisk install.
- stuff_perm: Subdirectories of /system on which permission are to be applied in case of a system installation. This variable exists because perming the whole system takes too long.
- `variant`: The name that will be in the filename of the released zip as well as will be shown on installation. It does not have to be related to the name of the defconf file (for example the defconf-unlp.txt file has variant "Backend" and creates the MinMicroG-Backend-*-*.zip package). Any string without whitespace will do.
- `ver`: The version number of the package, which is shown in the release filename and during installation. It can be anything except whitespace, but for convenience is integers along with decimals.
- `verc`: The version code for the package. It's only really used in Magisk installations's mod.prop, where Magisk compares it to decide if a version of the module is newer than the installed version. It strictly has to be an integer.
- `date`: The date of releasing the specific pack version, shown on installation.
- `minsdk`: The minimum Android SDK version the pack supports fully. It'll still install below that, but will show a warning to the user.
- `modprop`: The variable containing the entirety of Magisk's mod.prop, which will appear in your installed modules. Nothing really important here except verc, which is described above, and id, which has to be the same as modname variable from update-binary.
- `stuff`, `stuff_arch`, `stuff_sdk`, `stuff_arch_sdk`: Stuff variables are really space/tab-separated lists of all the objects (Relative to the root of the zip during flashing, or relative to either res or resdl directories in the build process) that are installed to be installed to device. It is going to be put through a for loop, so no whitespace is to be used in a single entry. Luckily, android system files aren't supposed to have spaces in their names/paths. For files in `stuff`, the file with that path is grabbed directly from res or resdl (in ascending priority), while for the other arrays, the files are grabbed from $(dirname [path])/-*-/$(basename [path]) (further clarification in build-your-pack.md).
- `stuff_other`, `stuff_old`: Just lists of stuff from other packs and stuff that used to be in any of the packs that I made for organisation. They have no purpose other than to be merged in stuff_uninstall.
- `stuff_uninstall`: Everything in this list is removed from system during a system installation and uninstallation. Should include everything in the pack, along with anything that used to be in it and anything that might be from alternative conflicting packs.
- `stuff_debloat`: Anything not from these packs that might conflict with it. For example GApps, other location providers, etc. They are removed (and backed up) during a system install and pseudo-debloated during a Magisk install.
- `stuff_perm`: Subdirectories of /system on which permission are to be applied in case of a system installation. This variable exists because perming the whole system takes too long.
## Functions in defconf files
- pre_build_actions()
- post_build_actions()
- pre_install_actions()
- post_install_actions()
- pre_uninstall_actions()
- post_uninstall_actions()
- `pre_build_actions()`
- `post_build_actions()`
- `pre_install_actions()`
- `post_install_actions()`
- `pre_uninstall_actions()`
- `post_uninstall_actions()`
Pretty self explanatory. Leave them blank with a return 0 if there's no use for them, not having them at all will cause errors.
## Variables in resdl-conf file
- stuff_repos: List of FDroid format app repositories that are to be downloaded and their contents used by update.sh. First column has their names, which are to be unique and are the key to access them in stuff_download. Second column is the URL, to which appending '/index-v1.jar' should result in an object downloadable by wget.
- stuff_download: List of actual objects that are put into resdl by update.sh. First column is the filepath inside resdl that it should be put in. Second column is the source that it comes from, which is one of local, direct, github, gitlab, or repo. Other columns depend upon the source and any extra columns are ignored. For local, third column is a path resolved against the repo directory from which the file is cp'd to the destination. For direct, the third column is a URL that must be downloadable using wget. For github and gitlab, the third column is [repo owner]/[repo name] from which the newest file is grabbed from the releases page, optionally filtering only for the regex-enabled suffix in the fourth column if provided. For repo, it's the [repo key]/[package name] of which the latest APK is grabbed, optionally filtering for the arch and minimum SDK if provided in the third column in the format ARCH:SDK (one of these variables can be ommitted but not the colon).
- `stuff_repos`: List of FDroid format app repositories that are to be downloaded and their contents used by update.sh. First column has their names, which are to be unique and are the key to access them in stuff_download. Second column is the URL, to which appending '/index-v1.jar' should result in an object downloadable by wget.
- `stuff_download`: List of actual objects that are put into resdl by `update.sh`. First column is the filepath inside resdl that it should be put in. Second column is the source that it comes from, which is one of local, direct, github, gitlab, or repo. Other columns depend upon the source and any extra columns are ignored. For local, third column is a path resolved against the repo directory from which the file is cp'd to the destination. For direct, the third column is a URL that must be downloadable using wget. For github and gitlab, the third column is [repo owner]/[repo name] from which the newest file is grabbed from the releases page, optionally filtering only for the regex-enabled suffix in the fourth column if provided. For repo, it's the [repo key]/[package name] of which the latest APK is grabbed, optionally filtering for the arch and minimum SDK if provided in the third column in the format ARCH:SDK (one of these variables can be ommitted but not the colon).
@ -4,12 +4,12 @@ The MinMicrog update, build, and install scripts were written with one primary g
To prove this, we're gonna write a new config and resdl-download file for an entirely new and relatively simple pack: the AuroraServices package containing just AuroraServices along with a perm file.
If you've read through this document (or perhaps want to play Russian roulette with rm and your device), there is a blank config file in defconf-dummy.txt that you can fill in.
If you've read through this document (or perhaps want to play Russian roulette with `rm` and your device), there is a blank config file in defconf-dummy.txt that you can fill in.
### update.sh and resdl-download.txt
### `update.sh` and resdl-download.txt
First, before making a pack, we gotta get the Aurora APK files from somewhere. We could've just downloaded and put them in the res directory, but they'd need to be updated and I'm lazy, so no.
What update.sh does for me is get everything I would need for a pack itself from a list of predefined sources and puts them in their proper places in the resdl directory so the build script picks them up. Now, update.sh knows what to get by executing and getting the variables from resdl-download.txt (open it and see) in the conf directory, so we're gonna add a few lines to it to get the three Aurora APKs downloaded automatically when we run the script.
What `update.sh` does for me is get everything I would need for a pack itself from a list of predefined sources and puts them in their proper places in the resdl directory so the build script picks them up. Now, `update.sh` knows what to get by executing and getting the variables from resdl-download.txt (open it and see) in the conf directory, so we're gonna add a few lines to it to get the Aurora APKs downloaded automatically when we run the script.
We could get them from FDroid, but their releases are usually out of date and I trust Whyorean so we're gonna grab them from his GitLab page. Fortunately, he has precompiled binaries on his releases page.
@ -22,9 +22,9 @@ For AuroraServices, we'll be keeping the file at path /system/priv-app/AuroraSer
```
To stuff_download.
But ding-ding! When you run the script, you may or may not notice that you may or may not get a valid APK file as the result. Why is that? open AuroraServices's GitLab releases page for yourself and see. The problem is that Whyorean provides a Flashable zip with each release too! How considerate. But that's a problem for the script, because as you may or may not have seen, our poor update.sh can get confused between different files in a release, and we can't exactly blame it; It has no way to know what we wanted and what we got are different, it's simply grabbing the latest file from a release's attachments.
But ding-ding! When you run the script, you may or may not notice that you may or may not get a valid APK file as the result. Why is that? open AuroraServices's GitLab releases page for yourself and see. The problem is that Whyorean provides a Flashable zip with each release too! How considerate. But that's a problem for the script, because as you may or may not have seen, our poor `update.sh` can get confused between different files in a release, and we can't exactly blame it; It has no way to know what we wanted and what we got are different, it's simply grabbing the latest file from a release's attachments.
Fortunately, I am wise. I foresaw this situation, and so I added a way to filter through the release files from a GitLab page. All we have to do is add a '.apk' in the fourth column, so that update.sh will first filter all the release attachments into only those having .apk at the end, and then grab the latest of them. So what we have to change that entry into is:
Fortunately, I am wise. I foresaw this situation, and so I added a way to filter through the release files from a GitLab page. All we have to do is add a '.apk' in the fourth column, so that `update.sh` will first filter all the release attachments into only those having .apk at the end, and then grab the latest of them. So what we have to change that entry into is:
@ -32,9 +32,9 @@ Note that while here I am using a simple suffix for this filtering since there a
Also note that exact same behaviour applies to the fourth column for the 'github' source type.
Additionally note that the fourth column for the 'repo' source type has a different function but similar purpose; It is the architecture and minimum SDK level to filter all the available APKs by.
Now, when we run update.sh, as long as the internet is still up, we will get a correct AuroraServices.apk where we wanted.
Now, when we run `update.sh`, as long as the internet is still up, we will get a correct AuroraServices.apk where we wanted.
### build.sh and defconf-aurora.txt
### `build.sh` and defconf-aurora.txt
For a new pack, we make a new defconf file. Note that the name in the defconf file is only used to execute the build command, the name of the zip in releases will be using the variant variable in the defconf. Open the defconf-aurora.txt file and see what the final result is.
@ -49,7 +49,7 @@ NOTE: I only reccomend doing this if you're familiar with shell scripts. DO NOT
- Then we fill up the empty values in modprop, seeing as id has to be the modname defined in update-binary, and the Magisk module template is at 1900.
- Since we have only two files (I wrote up the perm file) to be installed and they both are the same for various architectures and SDKs, we just add them to stuff.
(To understand how the others like stuff_arch and stuff_sdk work, I'd reccomend running update.sh and looking at the keyboard swipe and contact sync files.)
(To understand how the others like stuff_arch and stuff_sdk work, I'd reccomend running `update.sh` and looking at the keyboard swipe and contact sync files.)
- They don't have anything they conflict with, so nothing to add to stuff_debloat.
FriendlyNeighborhoodShane
3 years ago