MicroG in SFOS 3.4.0.22/24?

[zioamer]

To me microG works correctly with Sailfish 3.4.0.24. About your problem, have you checked that the fakestore has been activated from the “app permissions” menu from the AlienDalvik settings?

Open AlienDalvik Settings -> App and notifications -> App permissions -> enable system package replacement -> FakeStore.

The setting should look like this:

[danielfinsler]

in my installation, the self-check is missing the Play Store (Phonesky) has correct signature check mark. All other items are checked as correct.
How to fix that?

[Alex]

Did you manually copy your WhatsApp folder from an backup? If yes, then you have to recursively set the permissions correctly for the whole WhatsApp folder otherwise the app won’t be able to read/write to the directory. IIRC the correct permission is something like “media_rw” (I can’t check it right now).

[mercurio]

Great!!! Thank you!!!
I solved: now I can backup the chats locally and download all the media and documents they send me !!!
Thanks again and have a nice day!

[mercurio]

As for microG and spoofing permissions, I solved it by going back to version 3.3.0.16, installing and configuring microG and then updating to 3.4.0.24: everything works perfectly!

[carloni.marco]

After SFOS 3.4.0.22 installation I had same problem about Google account login and Microg app. I noted that after OS updating, it was not activated the permission of not afficial app within the “App Android Support”. After activation of that, all started to work properly.

[David]

In 3.4 on XA2, absolutely nothing worked apart from this. It probably required setting spoofing too. The instructions could be improved. Ask if you’re unsure.

Edit: see warning below.

yeoldegrove/sailfish-signature-spoofing-lxc

[David]

Warning, yeoldegrove’s solution breaks logcat.

Dr Yak writes about an alternate method in the comments here: https://together.jolla.com/question/204859/how-to-help-debug-android-support/?answer=204871#post-id-204871

[Mikkoj]

I cant login in microg.It just says there is account already.My account shows on Alien dalvik control and settings and users&accounts.Problem is that Whatsapp doesnt see Google drive for backup and everytime it goes to login page after that it says there is account already.So what to do?Thanks

[jameson]

Neither can I. If anybody has a solution for this it would be great. Currently I am not backing up Whatsapp data on Google Drive.

[shanti]

Hi, is there a way to kind-of-rollback a microg configuration and start from Scratch without the need to reinstall my phone ?

[David]

MicroG can be uninstalled easily enough. You might need to reinstall Alien Dalvik to get Android to work again.

[kalu.ucher]

Hello,

I cannot uninstall microG from Aurora due to a conflict package while trying to update it. Screen gets black when clicking the uninstall button.

I just want to update microG so I am trying to delete it and then reinstall it, how can I do it from pkcon?

Thanks

---

Solved:
It should be done by F-Droid, where the repository is. I had to uninstall it from there and then reinstall it again. I have it working again

[bundyo]

To post here for completeness:

[3.4.0.24] Signature spoofing doesn't work on a freshly flashed xperia 10 plus

Figured it out - the real problem why it will work on upgraded from 3.3 devices and not work on the clean install 3.4 is the only difference between them - the user folder name - defaultuser for clean 3.4 and nemo for 3.3 upgrades. So, the fix to get spoofing working is to stop AD and create a nemo symlink to defaultuser. Of course, if you already have a nemo folder, first move its contents to defaultuser, delete nemo and then symlink it.

[mced]

I love you, guys!!!

I fixed the problem with microG’s signature spoofing by making a symbolic link as @bundyo suggested:

devel-su
[Type your password]
ln -s /home/defaultuser /home/nemo
# As he has pointed out, move/backup files if you already got a /home/nemo folder

And then, fixed the WhatsApp issue by changing ~/android_storage/WhatsApp owner, as @Alex said:

devel-su
[Type your password]
chown -R media_rw:media_rw /home/defaultuser/android_storage/WhatsApp

Sailfish community never disappoints me. Now, let’s donate some chips to microG developers.

[tigas]

On the TJC thread they say that unpacking system.img to patch it for signature spoofing breaks logd, whether it’s opengapps/Google Play Services, microG, or yeoldegrove’s Docker process. I’ve just reflashed my XA2 to roll back yeoldegrove’s patch because I needed to see my (Sailfish) logs and his instructions on rolling back weren’t working. I also made the /home/nemo symlink, can I install microG without breaking logd?

[WedgeStratos]

If unpacking system.img to force enable signature spoofing is what breaks logd, and the symlink is one of the ways to fix signature spoofing, then you should be free to install MicroG now, enable signature spoofing for AD, restart AD, enable signature spoofing in MicroG GmsCore and FakeStore, and you’re golden.

I’ve not explored logd in any capacity, but I will say the update to 4.0.1.45/48 in early access has been a marked improvement in AD thanks to the new Android 9 base. This update should simply replace the system.img that is in /opt/alien currently, and that in turn could fix logd without needing to complete your rollback.

[David]

This update should simply replace the system.img that is in /opt/alien currently, and that in turn could fix logd without needing to complete your rollback.

Amazingly (to me anyway) it has. Both /system/bin/logcat and
lxc-attach -n aliendalvik – /system/bin/logcat are now working.

Spoofing went but ln -s /home/defaultuser /home/nemo alone fixed it.

Either AD 9 or default system.img allowed me to set up a Google account for Android too.

[DrYak]

For those who still need to patch stuff in their system.img file (I think I’ve heard people on the genuine Google Play Services need this) there is indeed a problem with most of these approaches breaking logcat and a few other tools.

To summarize:

• to work, logcat (and a few others) needs to access priviledged information
• this is handled by storing SELinux context parameters as xattr (extended attributes).
• nowadays, you’re most likely to be running on Linux installation that has policies that limits what you can write in xattr and are not allowed to write certain SELinux context parameters (that’s the case in Sailfish)
• so if you try to unpack system.img on Sailfish, you’ll lose some critical xattr because the unpacking step is not allower to write them in the temporary directory where you are unpacking.

If you’re fluent with shell tools, you can get inspiration from this:

https://gist.github.com/DrYak/fc31f558af023572e80f49ae08bb1224

that’s how I am patching the old maps v1 API into my system.img

i.e.:

• loop-mount system.img instead of unpacking it (i.e.: read files directly from the image instead of using unpacked).
• only for the specific sub-directories that you need to modify (in my case system/framworks and system/etc) create temporary directories.
• Try rsync-ing the temporary directories from loop-mount point, while preserving xattr and acls (XA)
• (some other linux users with buggy old versions of rsync have told me they need to run the rsync twice to make sure the xattrs get copied over).
• bind mount the temporary directories (in my case system/ is read straight from the loop-mounted system.img, but system/frameworks/ is actually read from the tmp/frameworks directory created above).
• write/patch/etc. what you need (in my case, uncompressing microG’s re-implementation of mapsv1.zip)
• make the new squash from the tree (thus most of the file will be fetched directly from the loop-mounted system.img. xattr are only read. at no point do you need to write any problematic xattr. Only the bind-mounted sub-directories have ever been throuhg a write stage, and they probably will NOT feature any problematic xattr that will be lost).

[ubuntuscofield]

Thank you sir this statement helped me with whatsapp being unable to download media be blessed