Hi all, is it possible to upgrade microG to the lastest version?
i’m using home assistant but it doesn’t find any location sensor on my 1.7s redmi note miatoll e/OS
so I want to try to upgrade microG as some home assistant forum suggests.
I add microG repository on f-droid but it doesn’t upgrade due signature difference.
someone can help me?
Regain your privacy! Adopt /e/ the unGoogled mobile OS and online services
Short answer: No.
/e/OS contains /e/'s fork of MicroG, built by /e/ and signed with their key. So it can only be updated with a newer version that is also signed with /e/'s key. In practice, this means that you can only update when /e/ ship a new ROM build containing an updated version.
If you want the latest, non-forked version of Microg, you would have to flash a different ROM
Thx for your clarification. @Manoj any plan to update migrog? Or the ability ton use the stock one?
Update probably in v1.8
@mebitek
When I had /e/ on my Axon 7 (Nougat) and was sticking with Pie on the mata (for awhile anyway), I did get rid of /e/'s microG and used upstream but it wasn’t so easy.
Anyway, the current microG included with /e/OS 1.7 is 0.2.26. 0.2.27 just came out last week.
Release v0.2.27.223616 · microg/GmsCore · GitHub
As the post linked in the previous message shows, it’s better to wait for 1.8 than to go through the troubles of trying to swap out microG.
@marcdw, as I am trying to keep a few devices alive which do no longer receive /e/ updates: could you please provide a sketch of what you did to replace /e/'s microG by a more recent upstream release?
I honestly can’t say how it all came together. The gist was
At the time I was using TWRP so that was all simple. Problem was after boot.
There was no microG in the launcher nor in Settings → Apps but there was some new oddly named apk showing up. The word Samsung was even in the label for some reason.
This is where my memory is fuzzy. Not sure how I got it all working.
I may have used the old/original Bromite WebView method: After placing the apk in /system one had to install the apk again as a user app. Like an update to itself.
Or I wiped the dalvik cache. Or both.
Regarding dalvik, I only noticed something recently. When the new Aurora Store was released I tried to update via F-Droid on some other older ROM. It failed due to signature mismatch. Uninstalled any existing updates as well as the apk in system. In TWRP I also removed its data directory.
Back in F-Droid the app still failed to install. Reported that data from app with different signature was present. Turned out it was the dalvik cached files. Manually removed them. Now it was okay to install Aurora Store.
Every trace had to be accounted for.
Back to microG. When you said upstream, referring to microG or /e/?
Using the former may be a pain but allows for future updates via F-Droid (microG repo).
Using the latter may/might/hopefully be less troublesome wrt signature. Might even be able to install the latest build as an update.
As far as microG upstream, another possibility is using a minimal installer with just the core items.
From MinMicroG is their minimal package MinMicroG-Minimal-UPDATELY-20230516004412.zip.
It includes microg, gsfproxy, the new FakeStore, and permissions. If the installer does the right thing it will replace existing. Unless existing have non-standard names or locations.
Sorry I do not have any actual instructions.
Given that I have no intention of using Android 12 on my mata, I may have to consider this stuff in the near future.
I’ve tried different variants to exchange com.google.android.gms = GmsCore.apk, including MinMicroG by FriendlyNeighborhoodShane. All attempts ended in a bootlopp of the installed TWRP recovery after booting and displaying the animated /e/ logo.
The cause will be: /e/OS contains /e/'s fork of MicroG, built by /e/ and signed with their key.
Thank you, @marcdw. I’ll give that a try.
I was referring to the official microG distribution. I do not intend to extract microG APKs from more recent /e/ releases.
Question: When doing the swapping did you ever wipe the dalvik cache?
On first run of a new ROM entries are generated for system apps and components. It was always customary to wipe dalvik when dirty flashing a ROM or after manually replacing a system app.
I used the Aurora Store issue as a possible example.
We have /e/ microG with signatureA. It has corresponding dalvik entries.
We swap out the apk for upstrean with signatureB.
On reboot when microG w/sigB is trying to load it does not match the dalvik entries associated with sigA. Resulting in problems.
As I mentioned before, I did swap out microG on the Axon 7 (no new builds) and the mata (held out on updating for awhile).
Long before /e/ I’ve had ROMs with microG via an assortment of installers like shadow53, ale5000, wearefairphone.
A couple didn’t use upstream. When the time came to update microG I got hit by the signature mismatch. Had to manually swap. Successfully but not always easy peasy.
Heh, sometimes forgetting to set perm to 644.
So yes, it is (or at least was) possible.
Example of dalvik files…
Thanks for your time @marcdw, it was a simple and successful matter after all. I started it more complicated than necessary.
I copied the new original microG apk (Services Core - com.google.android.gms) to the directory /system/priv-app/GmsCore/.
Then I deleted the /e/ version GmsCore.apk (0.2.25.223616-9 (13f943e)-noen) and renamed the new original microG apk (version 0.2.27.223616) to GmsCore.apk and yes …
… this is probably elementary - gave it permission 644 (rw-r-r).
Although TWRP 3.7.0_9-0 showed red error messages, it finally executed the commands.
Dalvik and cache I’ve not wiped. Whether microG works with all apps used - the question remains to be answered definitively. In any case, all apps relevant for me work.
Just an FYI.
microG has been updated to 0.2.28 which includes a major rewrite of the location stack. Individual backends are no longer used.
Release v0.2.28.231657 · microg/GmsCore · GitHub
Meant to handle issues with Android 13. It is not recommended to use it on older Android just yet (not sure about A12).
I updated on crDroid A11 before knowing better. 
None of my apps that use location make use of the baked-in Mozilla NLP. Only GPS was used. It was later brought to my attention that location-aware apps installed from the Play Store do make use of it, which I confirmed. Not sure of the technical reasons for that.
The new permissions are also not available on my A11. I do not have A12 so can’t test. Initially I added the perms to the relevant permissions files but later confirmed via pm grant that they do not exist in the OS.
So once again, hold off on that version.
An interesting thread…
Idea for the new location stack · Issue #1944 · microg/GmsCore · GitHub
Hey,
Do you use Home Assistant from App Lounge or F-Droid ? Because F-Droid version is minimal.
A few days ago, I tried the steps described here to update MicroG to version v0.3.2.240913 in the September 2024 version of @steadfasterX’s custom e-0.23-p-20240916-CUSTOM-vs986_usu ROM
I share here my findings originally posted there:
Result is a bootloop
Flashed Standard version of https://github.com/FriendlyNeighborhoodShane/MinMicroG-abuse-CI via Magisk Debug v. 28001. Restarted to recovery (TWRP), wiped dalvik/ART and cache. After flashing, installed as app the MicroG APK extracted from the module, followed by the Phonesky.apk also from the module. Both installed.
Edit: Added space to quote
I followed the steps in this thread (excluding my post) to update MicroG on e-0.21-n-20241017-UNOFFICIAL-grandprimeve3g ROM by @ronnz98
This time, the phone booted. Everything seems to be working. This is what I did:
This topic was automatically closed after 31 days. New replies are no longer allowed.
