[GAPPS][DAILY] Open GApps for Android; All Android Versions & Devices

[Nezorflame]

The issue with ARM package should be fixed - it was a broken APK update, which was removed from Gitlab (basically SDK27 APK was picked instead of SDK30 one).

 

[curiousrom]

Pixel 3a LineageOS 18.1 + open_gapps-arm64 Bootloop

@Nezorflame - FWIW two Pixel 3a users reported bootloop with Open GApps but working fine with MindTheGapps in the LineageOS subreddit here:

I have tried not restarting at all between installations, restarting to recovery, and booting completely before installing, and they all have the same problem. I'm going absolutely mad. What's going on? How can I fix this?

Pixel 3a Lineage OS 18.1-20211109-nightly open_gapps-arm64-11.0-micro-20211109

To which a LineageOS team member replied:

OpenGApps are hilariously broken, as they are every second week. Wipe the system and use MindTheGapps.

This is what happens when publishing untested builds.
***

 

[curiousrom]

Moto G6 Plus LineageOS 18.1 + open_gapps-arm64 Bootloop "Can't load android system"

@Nezorflame - FWIW a Moto G6 Plus user (A/B device) reported failed to boot with open_gapps-arm64-11.0-nano-20211111.zip but working fine with MindTheGapps in the LineageOS subreddit here:

"After rebooting, I get the lineageos loading symbol, it loads for ages, before rebooting and going back to recovery. ...Can't load android system, your data may be corrupt."

Pixel 3a LineageOS 18.1 + open_gapps-arm64 Bootloop

@Nezorflame - FWIW two Pixel 3a users reported bootloop with Open GApps but working fine with MindTheGapps in the LineageOS subreddit here:

To which a LineageOS team member replied:

This is what happens when publishing untested builds.
***

 

[Nezorflame]

Thanks, builds have been pulled, investigating the issue.

 

[curiousrom]

Broken Open GApps Builds Again!

Thanks, builds have been pulled, investigating the issue.

The era of publishing untested rolling releases of Open GApps is over.

Google is moving the goal posts all the time and that breaks stuff.

Better a monthly thoroughly tested release instead.

That's better for the reputation of Open GApps & also for the users instead of wasting their time with broken builds.
***

 

[Nezorflame]

The issue is fixed, new builds should be fine.

Will return with the news regarding what @curiousrom said soon (tm).

 

[Nezorflame]

In the meantime, here's a quick test A12 nano build for ARM64 for those who wants a taste
Initial setup worked for me, but might have different issues I haven't found yet.

https://sourceforge.net/projects/opengapps/files/arm64/test/20211112/open_gapps-arm64-12.0-nano-20211112-UNOFFICIAL.zip/download

 

[robin0800]

I am on android 10 and both 12th and 13th still crash on installation screen. Did your fix trickle down to 10 or is this a new problem?

 

[curiousrom]

I am on android 10 and both 12th and 13th still crash on installation screen.

What do you mean by "installation screen"?

Is that in recovery or when booting to system or in the Setup wizard?

If it's in the Setup wizard, it's while doing what?

Device model? ROM? GApps package? Clean install of update?

Did you try Open GApps build 2021-11-05?
***

 

[robin0800]

Setup wizard when trying to go to google account screen it never makes it, it crashes.
Rom lineage 10.1, gaps pico 05/11/210 and clean install.

 

[curiousrom]

Black Screen in Setup Wizard

A clean install LineageOS 18.1 Xiaomi Mi 6 (sagit) + Open GApps Stock user reported here in the LOS sub:

"Older Open GApps packages still don't seem to work completely right, the one from 11-05-2021 gives me a black screen when I choose to recover a backup...."
***

I am on android 10 and both 12th and 13th still crash on installation screen.

Setup wizard when trying to go to google account screen it never makes it, it crashes.
Rom lineage 10.1, gaps pico 05/11/210 and clean install.

***

 

[robin0800]

Sorry for wasting your time but it was not a gapps problem but a Rom problem. using an older Rom works with gapps 13 just fine.

 

[ipdev]

Hi all.

Long story short.

Looking for opinions on reversing the order of (or improving) the abi check.
OpenGApps - Github - Installer Script Line 1665 - Link

Reversing it (checking for cpu.abi first) should fix the wrong architecture being found on some devices.

device_architecture="$(get_prop "ro.product.cpu.abi")";
  if [[ -z $device_architecture ]]; then
    device_architecture="$(get_prop "ro.product.cpu.abilist")";
  fi;

I prefer looking for the newer prop first but, maybe this time it would be better looking for the older value first?

I have not tried it yet but, it should fix the architecture mismatch I recently ran into on my Poco F1.
The custom rom (used ro.product.cpu.abi) did not set ro.product.cpu.abilist in any of the prop files so OpenGApps set it from TWRP's default.prop.
Not sure if this affect other devices or not.
First time I ran into it and I have wiped, formatted and flashed my Poco F1 many times.
Not sure why this only showed up now.

I am using the official TWRP for the Device from twrp.me
TWRP for Xiaomi Pocophone F1 - twrp.me - WebSite - Link

beryllium:/ # for i in $(find / -name 'default.prop' 2> /dev/null); do echo $i && cat $i | grep 'cpu.abi'; done;
/default.prop
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
beryllium:/ #

Thoughts on including one of these values.

• ro.vendor.product.cpu.abilist
• ro.odm.product.cpu.abilist
• ro.system.product.cpu.abilist

ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.odm.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.system.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi

Cheers all.

Edit:
Dec. 15 2021 - Links to the PR and commit for reference.

OpenGApps - GitHub - Commit - Link
OpenGApps - GitHub - Pull request [# 944] - Link

 

[Nezorflame]

While I'm researching the reported issue, quick update to the A12 test package (only has apps updated to their SDK31 variant), package installer as well so apps should install fine.
Don't expect any serious work on A12 for now until we fix more important issues, but since it's already in a more or less working state, feel free to report anything you find so that I fix it when I have time.
ARM64 nano variant only for now: SourceForge

 

[Nezorflame]

Hi all.

Long story short.

Looking for opinions on reversing the order of (or improving) the abi check.
OpenGApps - Github - Installer Script Line 1665 - Link

Reversing it (checking for cpu.abi first) should fix the wrong architecture being found on some devices.

device_architecture="$(get_prop "ro.product.cpu.abi")";
  if [[ -z $device_architecture ]]; then
    device_architecture="$(get_prop "ro.product.cpu.abilist")";
  fi;

I prefer looking for the newer prop first but, maybe this time it would be better looking for the older value first?

I have not tried it yet but, it should fix the architecture mismatch I recently ran into on my Poco F1.
The custom rom (used ro.product.cpu.abi) did not set ro.product.cpu.abilist in any of the prop files so OpenGApps set it from TWRP's default.prop.
Not sure if this affect other devices or not.
First time I ran into it and I have wiped, formatted and flashed my Poco F1 many times.
Not sure why this only showed up now.

I am using the official TWRP for the Device from twrp.me
TWRP for Xiaomi Pocophone F1 - twrp.me - WebSite - Link

beryllium:/ # for i in $(find / -name 'default.prop' 2> /dev/null); do echo $i && cat $i | grep 'cpu.abi'; done;
/default.prop
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
beryllium:/ #

Thoughts on including one of these values.

• ro.vendor.product.cpu.abilist
• ro.odm.product.cpu.abilist
• ro.system.product.cpu.abilist

ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.odm.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.system.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi

Cheers all.

@osm0sis @mfonville WDYT?
I personally agree with this (and this is something @Nikhil suggested as well), so if there are no objections, might add this check.

BTW @ipdev feel free to post this kind of feedback/discussion on our Github as well, might be easier to communicate there.

Update: see https://github.com/opengapps/opengapps/pull/942 with this change.

 

[heithered]

I'm trying to set up a gapps config file to exclude same apps but couldn't manage to exclude Android auto and YouTube music. Can't find them at GitHub page, can someone help me please?

 

[osm0sis]

[WIP] Add permission check script by nezorflame · Pull Request #943 · opengapps/opengapps

Added Python script (modified version of MindTheGApps one) to check missing privapp permissions. Also modified add_sourceapp.sh so that it also checks missing permissions for the added APKs.

github.com

 

[curiousrom]

Testing Open GApps Packages Before Releasing Them

[WIP] Add permission check script by nezorflame · Pull Request #943 · opengapps/opengapps

Added Python script (modified version of MindTheGApps one) to check missing privapp permissions. Also modified add_sourceapp.sh so that it also checks missing permissions for the added APKs.

github.com

@Nezorflame - That's good.

Next step, maybe be inspired by an other thing that MindTheGapps does: release new packages only once in a while after they are tested by actual humans.

If you look here and here the last 3 MindTheGapps-11 releases were on:

Mar 28, 2021

Apr 12, 2021

Sep 20, 2021 - That's the most recent @ the present.

Play Store and Play Services automatically update themselves in the background regardless of the user's update settings in Play Store so there is no reason to churn out daily untested releases and the apps are updated when you login Play Store: either manually or auto-updated if you choose so.

Broken Open GApps Builds Again!

The era of publishing untested rolling releases of Open GApps is over.

Google is moving the goal posts all the time and that breaks stuff.

Better a monthly thoroughly tested release instead.

That's better for the reputation of Open GApps & also for the users instead of wasting their time with broken builds.
***

 

[Magendanz]

If you're running into the "Speech Services by Google" (a.k.a. GoogleTTS) crash on ARM 11.0, the workaround is to roll back to GoogleTTS v.26.2.4.385195680, which was last included in the 20210925 builds.

 

[ipdev]

Testing Open GApps Packages Before Releasing Them



@Nezorflame - That's good.

Next step, maybe be inspired by an other thing that MindTheGapps does: release new packages only once in a while after they are tested by actual humans.

If you look here and here the last 3 MindTheGapps-11 releases were on:

Mar 28, 2021

Apr 12, 2021

Sep 20, 2021 - That's the most recent @ the present.

Play Store and Play Services automatically update themselves in the background regardless of the user's update settings in Play Store so there is no reason to churn out daily untested releases and the apps are updated when you login Play Store: either manually or auto-updated if you choose so.

Just to note.

MTG is not perfect either.

Their installer script was broken.
[ROM][UNOFFICIAL][LineageOS][18.1/19.0][dragon] -> 2021-11-17 - xdaThread - Link
Four months to incorporate the PR to fix it.

Cheers.