Does it use the pm install -i parameter?My script doesn't need an apk (it reuse the installed one without the need to redownload or copy) and works also for split packages.
Does it use the pm install -i parameter?My script doesn't need an apk (it reuse the installed one without the need to redownload or copy) and works also for split packages.
Only for normal apk files, for split apk files it use pm install-create -i, but the best thing is that it find all apk parts without the need of you to provide them.
For split apps, I usually zip them up with a *.APKS file extension. I'm guessing your script would need that to be extracted first? Or can it parse the contents of an APKS without prior extraction?Only for normal apk, for split apk it use pm install-create -i, but the best is that it find all apk parts without the need of you to provide them.
My script doesn't install apps directly, it just "reinstall" them, without losing their data.For split apps, I usually zip them up with a *.APKS file extension. I'm guessing your script would need that to be extracted first? Or can it parse the contents of an APKS without prior extraction?
adb shell minutil.sh -i org.schabi.newpipe
Ok. So it's not useful for newly installed apps. I could just use Titanium Backup or Lucky Patcher (the latter is forbidden here for obvious reasons). But what they both have in common is that they use com.android.vending as the install source for all app installs (Titanium has a configurable option to toggle this). And they both work with splits/non-splits.My script doesn't install apps directly, it just "reinstall" them, without losing their data.
For example to reinstall NewPipe (it must be already installed), you just use:Code:adb shell minutil.sh -i org.schabi.newpipe
My use case is installing an app from Aurora Store, then reinstalling it with the script, so no annoying apk downloads from the browser (it should also fix the missing permissions if you installed an app before microG without the need of uninstall it first.Ok. So it's not useful for newly installed apps. I could just use Titanium Backup or Lucky Patcher (the latter is forbidden here for obvious reasons). But what they both have in common is that they use com.android.vending as the install source for all app installs (Titanium has a configurable option to toggle this). And they both work with splits/non-split s.
I don't mind APK downloads. I actually prefer them, I can keep an offline archive that way.My use case is installing an app from Aurora Store, then reinstalling it with the script, so no annoying apk downloads from the browser.
Droid guard is sandboxed by microG. And running as system app is not equal to having root privileges.microG: information & safety about SafetyNet/DroidGuard
Hi all,
I'm using microG because I don't want closed binaries running on my Android Device with privileged rights. In this context, I would like to get more information about SafetyNet and DroidGuard, but unfortunately I don't find anything relevant.
If I understood correctly, SafetyNet is a Google API that provides information for the other applications about the state of the device, concerning the security (like bootloader state and so on). In this system, DroidGuard is a closed binary tool that can perform signatures or check in the SafetyNet context.
As indicated in microG, the SafetyNet implementation is open source, but it depends of the DroidGuard binary to perform some operations.
So my question is: is it safe to enable SafetyNet into microG, due to the DroidGuard part? By safe I mean, no risk to see a closed binary doing some thing I don't want? Because, if the service is run as root, it could theoricaly do anything on the device, no?
I'm OK to use closed apps in a microG ROM due to the authorization isolation provided by Android, and I'm also OK to use some Google features. But I'm not OK to have closed binaries running without isolation on the device.
Thanks,
lama02.
OK thank you for your reply. So it's perfectly safe to run DroidGuard through microG, nice to know.Droid guard is sandboxed by microG. And running as system app is not equal to having root privileges.
I don't know. Is remote droid guard a left over from the times we had a separate droid guard helper app?OK thank you for your reply. So it's perfectly safe to run DroidGuard through microG, nice to know.
But in this case what's the purpose to use a remote DroidGuard (we can configure that in the advanced menu)?
This would probably be even more safe, but this would need a remote server that currently doesn't exist.OK thank you for your reply. So it's perfectly safe to run DroidGuard through microG, nice to know.
But in this case what's the purpose to use a remote DroidGuard (we can configure that in the advanced menu)?
I don't know. Is remote droid guard a left over from the times we had a separate droid guard helper app?
Thank you - ideed I searched for this remote DroidGuard but found nothing.This would probably be even more safe, but this would need a remote server that currently doesn't exist.
It isn't just that the server isn't up, the code for the server would also need to be implemented.
I wasn't talking about security but about privacy, it had to download a binary from a Google server so they at least know your IP.Thank you - ideed I searched for this remote DroidGuard but found nothing.
What do you mean by "even more safe"? If the DroidGuard process is sandboxed, what are the risks?
Perfectly clear, so it's acceptable for me. I just don't want a non sandboxed closed binary running on my phone.I wasn't talking about security but about privacy, it had to download a binary from a Google server so they at least know your IP.
It isn't like there is any problem but if you want to be completely anonymous a separate server would be better.
MicroG doesn't need to be a system app to be detected by signal. But it must spoof the signature of Google play services. Did you pick a spoofing patch for your build?I am trying to install microg on a rom that is pretty much still in beta but I was hoping far enough along that it would work. I built the rom and got it installed then tried to install microg using the "by hand method" ie. copy to /system/priv-app.
The first time i did this it boot looped i haven't installed by hand for years but it seems android x(no idea which x) introduced a requirement for a permissions file in /etc/permissions. I included one of those and got out of my boot loop but still I get the message from some products (let's take signal as an example) that Play services needs to be installed or updated.
I have the latest microg (latest -1 in priv-app) so i am wondering if somewhere there is something else (like the permissions xml file) which needs to be done in order to ensure it works properly? (I've tried blank-store and fake-store).
Another thought, maybe the permissions file should have a fixed name?
Thanks for any help.
I used this one "https://github.com/lineageos4microg...ofing_patches/android_frameworks_base-R.patch"MicroG doesn't need to be a system app to be detected by signal. But it must spoof the signature of Google play services. Did you pick a spoofing patch for your build?
test with this condition. "Hi,
I have created a script to automatically generate a device profile (usable by microG) from a device connected via adb: https://github.com/micro5k/microg-unofficial-installer/blob/main/utils/profile-generator.sh
Only adb and a device are needed (on Windows you also need busybox to execute the script).
I would like a feedback from all interested people.
PS: It can create a profile from most devices and even emulators but it only make sense to create a profile from devices that pass SafetyNet.
Yeah, I know how to put adb and other binaries in a custom location and then add that path to the system environment variables. I use lots of 3rd party binaries that aren't built into Windows, it's easier to call them that way because you don't need to specify their absolute path.The busybox linked by me is the most advanced and it doesn't need to be installed, just for example:Code:busybox sh ./script_name.sh
PS: On my repo this is really simplified (on Windows), you just need to:
1) Download the entire source repo from here: https://github.com/micro5k/microg-unofficial-installer/archive/refs/heads/main.zip
2) Extract it
3) Double click on cmdline.bat
4) Then just type:Code:profgen > my_profile.xml
The only thing more difficult is setup adb, just placing the file in the same directory may not work, the best thing is install it system-wide or alternatively place it in one folder and just setup PATH manually every time after step 3 and before step 4 with this:Code:PATH="C:/path_of_the_folder_of_adb;${PATH:?}"
Bit busy ATM, as soon as I can boot into Manjaro, I'll take that screenshot.No, the IMEI isn't supposed to be in the profile xml file, in fact when you use "sh ./profile-generator.sh > profile-name.xml" only the white text will go in the file.
The output of the script is:
- White text => what should go in the profile
- Green text => informational messages
- Brown text => warnings
- Red text => errors
@AnonVendetta
@tom.android
PS: My script was previously putting the exact serial number in the xml but now it will put an anonymized one.
The serial in the profile is just a template so there isn't any difference, microG only use the serial number to generate another rendomly but with similar characteristics.
The only reason I have added anonymization is that now people can share the xml without giving the real serial number.
View attachment 5875833
what is the best way to download this these days? little confused by all the different updates and forks.
is f droid repo a good place to install from still?