[HowTo] Install Google Play Services on baseport 8 devices from the phone itself (Tested working)

Suggested edits by a moron who initially did most of it wrong:

In 1, the command lines presentation is a tad confusing. Could the separate rows for each file be in separate boxes?

In 2, if you don't know code at all you can easily mistake to think that the command line does the stopping of Android Support. You need to do that from the Settings app.

In 3, please include the command line to make the sh file executable so that doesn't get lost in text.

In 4, please mention it's specifically Android 8.1 we need. I believe using the newest 9 would be a huge mistake.

In the second 3, please mention that downloading from Google Play doesn't seem to work, and as such you don't really need to and shouldn't sign up to your Google account during the configuration. The Play Services will work either way.

@teemu It's a wiki, so you or whoever else can edit based on own results in order to clarify and possibly correct the howto. Anyway I will try to improve it myself based on your suggestions. Feel free to add your edits.

Strange that someone remove my link to final script to use -.-

Ahhh and remember if something go wrong, before next use you must remove opengapps, opengapps_2 and squash-root directory

@Giacomo I'm a bit wary to presume editing myself, I rather other people re-check my suggested edits for factuality.

Do I really have to do this again after every Sailfish OS update? I have installed Google Play Services by following the previous instructions posted on Jolla Together with older Android/Sailfish versions, and never had any trouble with the Android/Play Services functionality after a Sailfish OS update.

Is the situation different now because of there being expected updades in the Android Support (which at this point still is beta on XA2)? The Play Services probably will remain installed, but will the future Android-related updades mess up something that will effect on them?

I'm not looking to re-re-install every Android app every time.

@teemu Yes. The problem is that now the Android system lies within a single compressed file (system.img). Otherwise there would not have been the need for all this stuff, we should just have copied the new files in the right places.

squashfs image is read only though? So installing Android apps doesn't change the image. But, the installed Android apps survive a Sailfish OS update that update the system.img, so the installation information apparently is stored elsewhere in the file system.

So, shouldn't apps installed with a modified system.img continue to work as is when there is a system.img update in a Sailfish OS update and you then (re-)modify that system.img in similar fashion? In theory at least?

@teemu That's what I expect, but we will only know when 3.1.0 is out.

As I do not gibber androidish. What is the difference between this approach (opengapps) and the one using microG and stuff like deodexing'?

@peterleinchen These are the real Google apps, microG is an open source more-or-less-compatible alternative.

@peterleinchen I discovered that when I used MicroG I have heavy drain battery, than with Google Play Services

What should I actually do with this? 2. Copy system.img.gapps to /opt/alien/system.img.

edit: i did factory reset, started everything from beganning, but i still cannot find this system.img.gapps. Even when searching all folders.

Was late but keep getting stuck at:

unzip:  cannot find or open ./Downloads/open_gapps-arm-8.1-pico-20190508.zip, ./Downloads/open_gapps-arm-8.1-pico-20190508.zip.zip or ./Downloads/open_gapps-arm-8.1-pico-20190508.zip.ZIP.

Should open_gapps-arm-8.1-pico-20190508.zip be placed in /Downloads or sub-directory Work and pass as parameter ./home/nemo/Downloads/open_gapps-arm-8.1-pico-20190508.zip or ./home/nemo/Downloads/Work/open_gapps-arm-8.1-pico-20190508.zip?

@aspergerguy did you used my .sh file ?

After some research and two or three factory resets I finally notice that file open_gapps-arm-8.1-pico-20190508.zip are having year/month/day before .zip-ending. The gapps-file downloaded from the webpage is have date when it was downloaded.

Therefore, the only way to use exact instructions (as i did), is to use download the file from 8th of May 2019 or make some manual changes :-)

Everything works like a dream and i feel silly.

@Stanislav1988 Yes I did thanks, all good now as stupid mistake on my part as already in "Downloads" so command should have been:

[root@Sailfish Downloads]# ./install_opengapps.sh ./open_gapps-arm-8.1-pico-20190508.zip

I'm trying to install this on xa2 plus and went through the process for a number of times: always different behaviours. Especially when starting Android services Google setup starts and I skip all the stuff related to sim and networks but it goes in a sort of loop and doesn't finish the setup properly. I also notice that the two folders opengapps and opengapps2 are not created at all: most likely because the initial setuo does not complete properly. I'm on latest Hossa. Thanks in advance for any suggestion ...

If you look at final command in "install_opengapps.sh" opengapps and opengapps2 are removed, so only present temporarily. What size is system.img.gapps as mine is 361.67MB compared to system.img.orig being 291.99MB? Are you carrying out process upon freshly formatted device or not? Got quite good at removing newly created squashfs-root folder to allow me to repeat the script:

rm -rf squashfs-root

Think I probably didn't wait long enough after re-starting Android support before hitting Play Store icon, but all came good in the end and downloads apps via network.

@aspergerguy Thanks for your reply. The script is successful, but then when I start Android support the Android setup starts almost immediately and wouldn't end even if I keep hitting "done". I don't know if there's something different with the dual sim version ... May be

@glalli Should have made clear my XA2 is also H4113 Dual Sim, although only currently has one data enabled SIM in place. What happens if you open Play Store, are you given option to sign-in?

@glalli try and look what will done, if you have mobile connection and you are able to connect to the ethernet, so you can log-in into Google Account

Ok I went through the process quite a number of times: always from scratch after resetting the phone. Only on a couple of occasions I was able to sign-in to google. Most of the times as soon as the Android setup starts it will ask a few questions about sim settings, network, etc, then your name , finally one screen that should be the last one and I click on "done", but then it starts from the beginning again. What starts immediately after re-starting Android support looks exactly like setup on an Android phone, but missing some stuff and it will never complete properly. If I try to open the store then the same setup process starts over and over. Thanks for your help

No luck at all installing google play. All went fine untill I need to copy system.img.gapps to opt/alien/system.img. Can't find system.img.gapps at all.

@glalli Resetting the phone should not be necessary, only removing /home/.android/data. Try skipping the Google login during the set up, as I have not tested this with a Google account. If you succeed then, but want to use your Google account, I suggest playing with the google_remove variable in the script (always stopping aliendalvik and removing /home/.android/data between each attempt) and seeing if the login succeeds.

@Gouneesz Did you used my script file in this turial? And search in the directory when you had a gapps file

For the record, I did do this with signing in to Google Account during the initial setup. I didn't have any issues, everything worked fine.

... and then I did sign myself out of the Play Store by removing my account (using coderus' AliendalvikControl from OpenRepos), and everything still worked, and then I signed myself into the Play Store again and everything still worked. I didn't have any issues with the Google Account.

Downloads from Play Store didn't work on wifi though.

I had hard time installing the rpm files in step 1 though, and had to do it in different way.

I cannot edit the question. Please change the line that installs squashfs-tools to rpm -U --oldpackage --nodeps https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/22/Everything/armhfp/os/Packages/s/squashfs-tools-4.3-8.fc22.armv7hl.rpm instead of rpm -i, and remove the instructions specific to 3.0.10. No need to get the different version, and it will work for both cases.

@Artur Done.

@Stanislav1988 yes I did use your script. If you mean install_opengapps.sh.zip.

Question:

does the logd daemon and logcat inside the container still work with your method?

I've notice that when unpacking (with unsquashfs) and repacking (mkdsquashfs) system.img some attributes are lost and logcat breaks.

I've tested it on a few desktop Linux boxes (as the signature spoofing for microG requires a bit more software and currenlt isn't compiled for smartphone) but maybe the specific version of squashfs you use inside the smartphone works better ? Maybe it's a x86 vs armv7 thing ?

I can circumvent the problem by using loop-mount and rsync -avPSHAX instead of unsquashfs.

@DrYak logd and logcat don't work. I get exacly the same stuff as you do when executing journalctl --follow

Okay, so the unsquashfs used here is as broken as the one on my desktops.

@Arthur could you please test an rsync alternative ?

unsquashfs system.img.orig

should be replaced with something along the lines of :

mkdir -p squashfs-root tmp-mount
mount -o loop,ro system.img.orig ./tmp-mount
rsync -avPSHAX --inplace tmp-mount/ squashfs-root
umount ./tmp-mount
rmdir ./tmp-mount

Could you please test ?

Is there any chance that a later version of squashfs might work correctly?

Like, the topmost armv7hl one in https://www.rpmfind.net/linux/rpm2html/search.php?query=squashfs-tools:

squashfs-tools-4.3-20.fc31.armv7hl.rpm

This Playstore port works like a charm! I can even download apps though Playstore with WIFI only. It hugely extends the services on my Sony Xperia XA2. Thanks for this wiki! p.s. I use vendor bin Nile version 16 on Hossa 3.0.3.10.

@teemu :

My desktop distro is a rolling one - openSUSE Tumbleweed - and even if it already has the latest 4.3 version of squashfs it shows the same buggy behaviour.

I tried this two times (factory reset in between) and arrived to the same issues. Aptoide does not work, so I installed APKpure instead. That works, I can install a news app like NOS (Dutch). First try I could download apps over Wi-Fi (I think), second time not. After rebooting to get mobile coverage, I entered my credentials in Play Store, and downloaded Whatsapp. Could not activate Whatsapp account: "This app won't work properly unless you allow Google Play services' request to access the following: SMS". First try I had a similar experience. Another app I tried, Garmin Smartphone Link, complained about Bluetooth not being accessible.
Steps taken after installing opengapps:
Hello - English
Connect to mobile network - Skip
Connect to Wi-Fi - Skip
Warning pop-up "Without connection..." - Continue
Date & Time (was correct) - Next
Name - X - Next
Google Services - Help apps find location - Off, Send usage and Diagnostic data - Off - Accept
Notification on Sailfish home screen, pressed that
Play Protect, pressed gear symbol to find Play Protect settings - Off - pressed Back arrow
Google Services screen - Back up to Google Drive - Off. Can't remember what came after that. Probably I accepted this screen. Don't think there were options to access SMS etc.
When prompted in Whatsapp about SMS access, there was an option to Open Settings. New Android window opened, but nothing reacted to touch.
I hope you have a solution, and thanks Giacomo for delivering for this break-through anyway!

@rob_kouw I think I answered you in other thread. But, go to Settings - Apps - Whatsupp - Open Android Settings and give Whatsapp rights to use SMS. And then try again. Try both mobile and wi-fi, in case there's a network issue too.

(there is a bug that makes Android apps unresponsive when they are opened by another Android app, which apparently happens to you when Whatsapp calls up the (Android) Settings app.)

Great! It works. (It doesn't work for Garmin Smartlink, but maybe I should not expect a difficult subject like Bluetooth to work.) Thanks!

@DrYak I tried to do this on my XA2/3.0.3.10 with the changes you suggested to the sh script:

$ devel-su ./install_opengapps.sh open_gapps-arm64-8.1-pico-20190530.zip
Password: 
rsync: --sparse cannot be used with --inplace 
rsync error: syntax or usage error (code 1) at main.c(1554) [client=3.1.0]
[nemo@Sailfish Downloads]$

The rsync package installed on my Sailfish is rsync-3.1.0+git2-1.4.1.jolla.armv7hl, should be the vanilla one.

@DrYak how did you manage to use --sparse and --inplace together? I understand you got it working for yourself?

Using --sparse and --inplace simultaneously requires:

• a recent enough ( >= 3.1.3) rsync version (its disallowed on older).
• a filesystem that supports hole-punching (ext4, btrfs)

works on recent desktop distros (e.g openSUSE Tumbleweed), but indeed the one inside Sailfish is older and thus you must drop either one. (there aren't many sparse files, there isn't much space saving).

Note: i got i working myself... for MicroG.

Which runs on the desktop in a docker container because you need to run some signature spoofing patches that require a full Java stack.

My mods use a very recent docker base layer, so I completely forgot about old rsync versions on plain Sailfish as used for Google Play Service blobs here.

My bad.

Debian stable and RaspBian should suffer from the same problems (ships with 3.1.2).

I tried manually doing what the script does on Linux Mint that should be up to date, but probably is having too old rsync still.

But, I can leave --sparse out then? I tried that too on my XA2, but there came some fatal issue in the umount bit. Apparently tmp-mount was still active or something. Terminal stuck and the phone auto-rebooted.

• --sparse tries to keep sparse files sparse, i.e. empty part of file that don't contain data and thus don't need to actually be written on disk. I'm using it out of habit, but I don't think there are many in Android.
• --inplace modifies files directly. Other wise the default behaviour is make a new temp copy and swap the files once copying is finished. If you're running this pipeline only once it doesn't make any difference. If you're running multiple tries, this will simply just replace the couple of byte you've modified, instead of the whole file.

You can leave out both, I'm just using them out of habit (when uploading multiple attempts at patching system.img you can imagine the time saving of just overwriting the tiny part that changed between attempts, vs. create a whole new copy of the file each time)

Apparently tmp-mount was still active or something.

I would suspect that some background process decided to go inside and do stuff. Probably the media indexer ? You can prevent it from indexing something by creating a file.

touch .nomedia

The problem is that you're probably running the script in your home and you probably want it indexed, so don't forget to

rm .nomedia

at the let the indexer go there again.

(I think I should be also possible to prevent indexing if you use a hidden file name, so ./.tmp-mount instead of ./tmp-mount - note the leading dot).

just for the record, the important options of rsync are:

• a (archive) copies nearly everything
• H (hard-links) hard links are also carried over (two different files being actually the same on disk)
• A (ACLs) rights beyond the simple chmod's u/g/o "rwx" are also carried over.
• X (xattr) extended attributes are also copied.

this last one, i think, is what the bug squashfs loses.

I tried so hard, and got so far. But, in the end, it doesn't even matter. journalctl --follow still has the same old logd failure action going after my attemps to use rsync instead of squashfs.

I don't have some lyrics to creatively riff on, but - in a moment of "palm meets face":

• exactly which system.img did you loop-mount and rsync from? the original pristine one that came from Jolla? or the one that already got trashed during a previous attempt?

I mean it's nice to put tons of efforts to keep the xattrs, but if they aren't there to begin with...

Didi you get the

WARNING: re-using existing system.img.orig

message ? And was that existing file copied from the original file?

If you lost the original file, force re-install the package aliendalvik.

I suspected something like that having happened to system.img myself, and tried removing and reinstalling Android Support but managed to only mess my system so that I had to do a factory reset.

And with this factory reseted installation, I executed the actions in this guide, using rsync to unsquash the extremely pristine system.img.

And the damn logd stuff just keeps going on when I journalctl --follow.

My alterations to the script (replacing the row "unsquashfs system.img.orig"):

mkdir -p squashfs-root .teemu
mount -o loop,ro system.img.orig ./.teemu
rsync -aPHAX .teemu/ squashfs-root
umount ./.teemu
rmdir ./.teemu

The Google setup btw is much messier now than in May when I did it previously. Android setup windows open other setup windows, which tend to be unresponsive.

Are we sure that mksquashfs doesn't do something nasty with them xattrs which squashfs-tools can't handle to the other way either?

according to mksquashfs --help:

-xattrs stores extended attribues (default)

it Should be storing them by default...

if you pay attention, at the end mksquashfs should output a summary, and when comparing the unsquash vs rsync versions, the latter should have a line with some counts about extended attributes (don't remember exactly, don't have my laptop around atl the moment).

It says this:

inflating: opengapps/META-INF/CERT.RSA
mksquashfs: /usr/lib/liblzma.so.5: no version information available (required by mksquashfs)
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on system.img.gapps, block size 131072.
[====================================================================================================-] 5775/5775 100%

Squashfs 4.0 filesystem, lz4 compressed, data block size 131072
compressed data, compressed metadata, no fragments, compressed xattrs
duplicates are not removed
Filesystem size 354097.47 Kbytes (345.80 Mbytes)
58.80% of uncompressed filesystem size (602189.67 Kbytes)
Inode table size 52562 bytes (51.33 Kbytes)
41.13% of uncompressed inode table size (127805 bytes)
Directory table size 28496 bytes (27.83 Kbytes)
57.28% of uncompressed directory table size (49752 bytes)
Xattr table size 1065 bytes (1.04 Kbytes)
26.92% of uncompressed xattr table size (3956 bytes)
No duplicate files removed
Number of inodes 2060
Number of files 1454
Number of symbolic links  340
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 266
Number of ids (unique uids + gids) 6
Number of uids 3
root (0)
system (1000)
logd (1036)
Number of gids 6
root (0)
system (1000)
cache (2001)
shell (2000)
sdcard_r (1028)
logd (1036)
[nemo@Sailfish Downloads]$

If I do it with -noX ("do not compress extended attributes"), Xattr table size is 3782 bytes (3.69 Kbytes), and 95.60 % of uncompressed xattr table size (3956 bytes)

The logd issue will keep happening with this system.img with uncompressed Xattr too... and Android apps seem to refuse to start, though Android support will

doing just a de-pack / repack of the original system.img, from the laptop

my table when doing rsync: 4036 (compressed to 1089)

my table when doing unsquashfs: 3916 (compressed to 1038)

there's 120 bytes of xattrs lost somewhere between the two.

Your attempts seems closer to my unsquash attempt.

To tired (and no USB cable) to redo the tests on the smartphone, but in the past, the unsquash one was making problems, not the rsync one.

I don't know waht to do to help.

Oh I'm quite happy with this level of functioning and the slight extra overhead that the patched Android runs. I don't really need logd for anything myself. This was just intelligence gathering mission in case someone wants to fine tune the process, or maybe unearth the bug that's doing it.

And then I executed the same script (with rsync) on my Linux Mint, same system.img.orig and other input, and with this version of system.img.gapps there's no journalctl overhead and logd works just fine.

I match your Xattr count after this run: Xattr table 4036 bytes, compressed 1089

squashfs-tools 1:4.3-6ubuntu0.18.04.1
mksquashfs version 4.3-git (2014/06/09)

rsync 3.1.2-2.1ubuntu1
rsync version 3.1.2 protocol version 31

So to find where the xattr loss happens, I guess one would have to unsquashfs system.img.orig and rsync system.img.orig on both XA2 and on the computer and then mksquashfs the versions of squashfs-root with the other device and compare the results.

But... it has to be the rsync on Sailfish. The uncompressed number obviously is what it is after rsync, the compressed number is what comes from the mksquashfs compression. Sailfish rsync gives me 3956 uncompressed bytes, Linux Mint rsync 4036.

Unless mksquashfs in Sailfish does something silly when taking the uncompressed input from the squashfs-root folder.

edit: just for laughs, I executed the unsquashfs version of the script on my Linux Mint laptop: Xattr table size 1088 bytes compressed, 4036 bytes uncompressed. It's 1 byte less in the compressed Xattr, but both rsync and squashfs versions of the script end with the same 4036 bytes.

On Sailfish OS, unsquashfs return me 1038 compressed and 3916 uncompressed bytes of Xattr. rsync return 1065 compressed and 3956 uncompressed bytes of Xattr. There is a noticeable difference of 50 bytes between unsquashfs and rsync when doing it on the phone, and both lose xattr information compared to the Linux Mint versions of unsquashfs and rsync.

thanks for you exploring this.

(other possible source of loss: for some reason the XA2 isn't capable of storing them correctly. Maybe trying to rsync directories over SSH between the laptop and xa2 to further explore ?)

@DrYak you said in the other thread that you filed a bug ticket with Jolla (on the unsquashfs?), but the xattr loss problem seems to be a bigger issue with unsquashfs/mksquashfs/rsync when executed on the phone (at least XA2).

Can you update the ticket, and would we maybe need a separate topic on TJC for the issue to entice interest?

@DrYak@teemu Seems to be a bug in this version of rsync. Running it twice copies the correct xattrs on the second try. See my answer for a script that patches the image without breaking logcat: https://together.jolla.com/question/205890/howto-install-google-play-services-on-baseport-8-devices-from-the-phone-itself-tested-working/?answer=207956#post-id-207956