@ -53,16 +53,16 @@ Dirty flashing not recommended. you'll mess up all your permissions and may even
The maker does not support or endorse dirty flashing. It will harm you and your loved ones. Don't come complaining to me.
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.
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.
- 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.
The zip debloats the 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.
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.
For support with flashing:
If you flashed through recovery, provide its logs.
@ -75,7 +75,7 @@ cd to this directory and run:
```
To download all the assets to resdl directory.
NOTE: This will download a zipsigner.jar (topjohnwu's rewrite of the AOSP version) into resdl/util, if the file does not exist already. The source can be found in the Magisk repo, and prebuilt binaries in attachments [here](https://forum.xda-developers.com/showpost.php?p=56621542)
NOTE: This will download a zipsigner.jar (topjohnwu's rewrite of the AOSP version) into resdl/util, if the file does not exist already. The source can be found in the Magisk repo, and prebuilt binaries in attachments [here](https://forum.xda-developers.com/showpost.php?p=56621542)
@ -17,14 +17,14 @@ For making your own pack and config file, check custom-pack.md
- 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 apear 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-separeted 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).
- 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.
- service (optional): The contents of what should be in service.sh in magisk installations and init.d scripts in system installations.
- addond (optional): The contents of what should be in the addon.d scripts in system installations. No need for this on Magsisk, since modules are already stored in data.
- service (optional): The contents of what should be in service.sh in Magisk installations and init.d scripts in system installations.
- addond (optional): The contents of what should be in the addon.d scripts in system installations. No need for this on Magisk, since modules are already stored in data.
@ -7,7 +7,7 @@ To prove this, we're gonna write a new config and resdl-download file for an ent
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
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.
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.
@ -22,7 +22,7 @@ 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 pag 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:
```
@ -32,7 +32,7 @@ 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 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.
@ -58,7 +58,7 @@ There are several other ways to have your ROM support sigspoof too:
- Using the SmaliPatcher application on PC (shrouded in mystery)
- Proprietary, windows only
- [Here](https://forum.xda-developers.com/showpost.php?p=78958124) OP of XDA thread admits they do not know of the source code, probably do not even have access to it
- [Here A](https://forum.xda-developers.com/showpost.php?p=80287799), [Here B](https://forum.xda-developers.com/showpost.php?p=80287989), [Here C](https://forum.xda-developers.com/showpost.php?p=80292041), It connects to arbitrary Russian IPs and OP says it's probably nothing
- [Here](https://forum.xda-developers.com/showpost.php?p=80287799), [Here](https://forum.xda-developers.com/showpost.php?p=80287989), [Here](https://forum.xda-developers.com/showpost.php?p=80292041), It connects to arbitrary Russian IPs and OP says it's probably nothing
You also need to watch which apps you grant sigspoof permissions to. I am not aware of any app that legitimately requires sigspoof other than MicroG.
@ -122,7 +122,7 @@ if no:
If yes:
- Ensure you don't have an adblocker blocking the domain, whitelist it in adaway and similar:
mtalk.google.com
If you can't get any app to register for Google Cloud Messaging, try dialing this:
\*\#\*\#2432546\#\*\#\*
@ -157,7 +157,7 @@ You can retieve your contacts directly from your Google account in a vcf file:
You should also be able to sync contacts with Google without proprietary apps or microG using the open-source CardDAV client DAVdroid (available on F-Droid or Play)
- First of all, go to https://www.google.com/settings/security/lesssecureapps
With your account and enable the setting
- When logging in with DAVDroid, Use "Login with URL and user name"
- When logging in with DAVDroid, Use "Login with URL and user name"
- Base URL: https://www.google.com/calendar/dav/your_gmail_id@gmail.com/events
FriendlyNeighborhoodShane
4 years ago