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.
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.
1 Like
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
2 Likes
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
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.
Hi, is there a way to kind-of-rollback a microg configuration and start from Scratch without the need to reinstall my phone ?
MicroG can be uninstalled easily enough. You might need to reinstall Alien Dalvik to get Android to work again.
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 
2 Likes
To post here for completeness:
7 Likes
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.
9 Likes
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?
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.
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.
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:
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).
2 Likes
Thank you sir this statement helped me with whatsapp being unable to download media be blessed