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

[curiousrom]

Re: Testing Open GApps Packages Before Releasing Them

MTG is not perfect either...

I never said it was & that was not my point.

Four months to incorporate the PR to fix it...

How about almost 2 years to check the priv-app permissions with a script?

See the quote in this post.

It takes time to do stuff in volunteer based projects & that's expected.
***

 

[Magendanz]

I'm so excited to finally have Android 11 stock builds, but am seeing a WebView problem on the Galaxy Tab A 8.0 (SM-T290, ARM64) that seems related to issues #820 and #804. Setup cannot progress past attempting Google Play Services sign-in and skipping setup results in the same problem when logging into the Play Store or Chrome, showing only a black screen and the navigation bar. If I check WebView Implementation in Developer Options, it shows None.

Can anyone recommend a workaround for this? Previously, we just needed to match versions for Chrome and Trichrome, but they both seem to currently be 81.0.4044.138.

So, I did ultimately find a workaround: Adding WebViewGoogle to the gapps-config.txt allowed me to get through the Setup Wizard and Google Play Services sign-in. WebView implementation shows as "Android System WebView 94.0.4606.71" (which I assume it got from my underlying GSI) and everything seems to be working fine now.

Shouldn't it be installing WebViewStub for Android 7.0+, though?

 

[Md Husain]

Hello,

In the open_gapps_logs file, there is a line, Google Pixel Features | false

So actually which devices it will support on?

Is it possible to force this features to support, making Google Pixel Features | true ?

 

[WasikFahim]

Copied from log file: "INSTALLATION FAILURE: This Open GApps package cannot be installed on this
device's architecture. Please download the correct version for your device."
I'm using arm64 device (redmi k20 pro) but can't install test build of A12 open gapps. I've downloaded arm64 version though.

 

[myxal]

Cheers.
TL;DR: Can any developer tell me if it's okay for a ROM developer to provide android version info only via the ro.vendor.build.version.* properties? (Ie. without the ro.build.version.* properties, which the opengapps installer is currently looking for).

I have a Nexus 4 which I'm keeping alive with CarbonROM (8.0, Android 10). Since one build about 6 months ago, opengapps stopped being installable, always complaining about insufficient android version. The version detected by opengapps installer would be 5.1.1 - which - I'm guessing - is the version of android the recovery is using.

After tinkering with the installer script to find out what's going on, I concluded that the properties that the installer is checking (ro.build.version.release and ro.build.version.sdk) are not present in any property file shipped by CarbonROM in the current build. I now have noticed however, there are ro.vendor.build.version.release and ro.vendor.build.version.sdk properties under /system/vendor/build.prop. Is this some new normal? Does opengapps need to fix the installer, or is this a broken ROM build?

 

[ipdev]

Cheers.
TL;DR: Can any developer tell me if it's okay for a ROM developer to provide android version info only via the ro.vendor.build.version.* properties? (Ie. without the ro.build.version.* properties, which the opengapps installer is currently looking for).

I have a Nexus 4 which I'm keeping alive with CarbonROM (8.0, Android 10). Since one build about 6 months ago, opengapps stopped being installable, always complaining about insufficient android version. The version detected by opengapps installer would be 5.1.1 - which - I'm guessing - is the version of android the recovery is using.

After tinkering with the installer script to find out what's going on, I concluded that the properties that the installer is checking (ro.build.version.release and ro.build.version.sdk) are not present in any property file shipped by CarbonROM in the current build. I now have noticed however, there are ro.vendor.build.version.release and ro.vendor.build.version.sdk properties under /system/vendor/build.prop. Is this some new normal? Does opengapps need to fix the installer, or is this a broken ROM build?

Nice investigating and a good question.

The OpenGApps scripts can be a little confusing.

To clarify.
The installer script uses the SDK level.

# Get ROM SDK version
rom_build_sdk="$(get_prop "ro.build.version.sdk")"

[GitHub] - Installer script lines 1635-1636 - Link

The value found is compared to the OpenGApps build ($req_android_sdk) that you are trying to install.

# Check to make certain user has proper version ROM Installed
if [ ! "$rom_build_sdk" = "$req_android_sdk" ]; then

[GitHub] - Installer script lines 1651-1652 - Link

--

I checked CarbonROM 8 for mako.
Extracted and mounted the system image.

The system build prop does contain ro.build.version.sdk.

Part of the system/build.prop

# begin common build properties
# autogenerated by build/make/tools/buildinfo_common.sh
ro.system.build.date=Sat Nov 20 05:22:56 CET 2021
ro.system.build.date.utc=1637382176
ro.system.build.fingerprint=google/occam/mako:5.1.1/LMY48T/2237560:user/release-keys
ro.system.build.id=QQ3A.200805.001
ro.system.build.tags=release-keys
ro.system.build.type=user
ro.system.build.version.incremental=033719fce0
ro.system.build.version.release=10
ro.system.build.version.sdk=29
ro.product.system.brand=google
ro.product.system.device=mako
ro.product.system.manufacturer=LGE
ro.product.system.model=Nexus 4
ro.product.system.name=occam
# end common build properties
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=QQ3A.200805.001
ro.build.display.id=QQ3A.200805.001-carbon@saturn.carbonrom.org
ro.build.version.incremental=033719fce0
ro.build.version.sdk=29
ro.build.version.preview_sdk=0
ro.build.version.preview_sdk_fingerprint=REL
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=10
ro.build.version.security_patch=2021-11-05
ro.build.version.base_os=
ro.build.version.min_supported_target_sdk=23
ro.build.date=Sat Nov 20 05:22:56 CET 2021
ro.build.date.utc=1637382176
ro.build.type=user
ro.build.user=carbon
ro.build.host=saturn.carbonrom.org
ro.build.tags=release-keys
ro.build.flavor=carbon_mako-user
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
ro.product.locale=en-US
ro.wifi.channels=
# ro.build.product is obsolete; use ro.product.device
ro.build.product=mako
# Do not try to parse description or thumbprint
ro.build.description=occam-user 5.1.1 LMY48T 2237560 release-keys
ro.carbon.device=mako
# end build properties

Not sure why SDK29 is not found for you.

Cheers.

PS.
I charged mine up and will test once I (re)partition it.

 

[myxal]

Thanks for taking a look at this.

I checked CarbonROM 8 for mako.
Extracted and mounted the system image.

The system build prop does contain ro.build.version.sdk.

Interesting. I only checked the system partition (didn't have a linux box ready) after installing CarbonROM with TWRP, and manually resizing the partition (via adb shell):

# e2fsck -fy <system partition>
# resize2fs <system partition>
# e2fsck -fy <system partition>

I just installed the ROM again, without resizing or checking the partition - that file exists but is empty.

My /system/addon.d only has "50-hosts" and "70-gapps" in it, and none of those touch the file AFAICT. Is there anything else that might be touching the system partition after the image is written to the partition? (aside from CarbonROM's own installer, which I'm just about to check)

 

[myxal]

I think I see what's going on...

• CarbonROM ROM's system partition image is sized to 1.2 GiB.
• The image of the system partition itself does not contain the build.prop file - it's part of the zip archive as a dedicated file.
• The 1.2G partition size is not enough for opengapps nano, which I wish to use.
• opengapps' addon.d script backs up opengapps and restores it after a new CarbonROM system image is recorded on the partition. Crucially, this happens before I have a chance to manually resize the partition to fit opengapps (my system partition is 2 GiB)
• (My guess) The system.build prop should be copied after the addon.d scripts are executed.
• However, restoring the opengapps backup onto the not-yet-resized system partition exhausts all free space, so when the installer tries to copy build.prop file, it only manages to create the directory entry, but doesn't copy any data. (How the **** is this not detected as an error is beyond me.)

My question for opengapps would be - does the opengapps backup contain anything that's not in the installer? (I would just nuke the system partition before installing CarbonROM and installing opengapps as "new")

I used to have an addon.d script to do the resize automagically during ROM installation years ago, but recall it not working for some reason. I found and will try this one to see if it works.

EDIT: I got the script working (the payload version from here), and was a bit surprised - the filesystem was grown, and the gapps script executed with errors on chcon (couldn't change context), so actually I ended with a filesystem filled less than it was before. (0.8 GB vs 1.2 GB). Nevertheles, build.prop was copied successfully and opengapps installation worked without issues.

 

[dwardo]

Bootloop here with open_gapps-arm64-11.0-nano-20211203.zip

Went back to 20211125 that works

 

[osm0sis]

Bootloop here with open_gapps-arm64-11.0-nano-20211203.zip

Went back to 20211125 that works

In before curiousrom!

Reported it to the team.

Any in between those working?

Edit: Also some logs of the bootloop and GApps install would be nice to help narrow it down.

 

[curiousrom]

Bootloop here with open_gapps-arm64-11.0-nano-20211203.zip

Went back to 20211125 that works

Bootloop thrown back to recovery reported on clean install of Galaxy S III Neo (Samsung Camera) (s3ve3gjv) + LineageOS 18.1 + open_gapps-arm-11.0-nano-20211203 here.
***

Edit: @Nezorflame added build date as reported by the user.
**

 

[dwardo]

In before curiousrom!

Reported it to the team.

Any in between those working?

Edit: Also some logs of the bootloop and GApps install would be nice to help narrow it down.

Bootloop to twrp to be precise
Haven't tried anything in between
I can redo install to get you a last_kmsg.log and install.log. Anything else you need ?

 

[dwardo]

Bootloop to twrp to be precise
Haven't tried anything in between
I can redo install to get you a last_kmsg.log and install.log. Anything else you need ?

Attached are the gapps install logs.
Can't find the previous kernel log... Don't have /proc/last_kmsg or /sys/fs/pstore/console-ramoops

 

[curiousrom]

@Nezorflame - A user reported here bootloop with Nano but not with Pico: open_gapps-arm-11.0-nano-20211202.zip on Nexus 7 & clean install of official LineageOS 18.1.
***

 

[sevenrock]

Hi,
Play Store and Play Services seem out-of-sync:

logcat80:12-04 16:23:52.531 4995 5255 W GooglePlayServicesUtil: Google Play services out of date for com.google.android.youtube. Requires 214680000 but found 214515037

12-04 22:14:10.290 8167 8277 W GooglePlayServicesUtil: de.rki.coronawarnapp requires the Google Play Store, but it is missing.

using this tree

Files · c595fb978256a0a8ae191aa3c8383d91f1f6bb03 · OpenGApps / arm64 · GitLab

ARM64 sources and releases for OpenGApps https://opengapps.org/?arch=arm64

gitlab.opengapps.org

with opengapps included into my private los-18.1 build using https://github.com/opengapps/aosp_build

Will try to revert https://gitlab.opengapps.org/opengapps/arm64/-/commit/8810d419f3e0806aae3bb41a9bd4d493bfa96dbb in the next build and report back.
EDIT 1: Was not enough, will try to remove the Google Play services from Nov 29th as well...

 

[Game-R]

Hi there,
Would like to inquire if it's a known issue that Open GApps would break Wi-Fi Direct and Miracast?

I have a Sony Xperia Z5 flashed with an Android 7.1.2 ROM that I use for a car diagnostic display that was able to connect to a Hudway Cast device that uses the Miracast protocol. I've discovered that upon completing running 7.1 version of Open GApps Aroma installer, to remove some apps I don't want in the phone (I don't want GMail and YouTube that came in the ROM to take up space and memory), the device isn't able to detect any wireless (Miracast) displays.
I also noticed that the Wi-Fi Direct configuration page, that was working fine before, is completely dead: Clicking on "Search For Devices" would do nothing and upon attempting to rename the device would result in a "Failed to rename device" error message.

I've tried installing all of the GApps and selected not to remove any of the LineageOS or AOSP programs to see if there was something I was removing or not including in the installation that was causing this problem, but I found that regardless, after completing GApps installer, the phone's Wi-Fi Direct and Miracast capabilities just dropped dead.

Any advice on this and what I would need to do to get Miracast working on my phone would be greatly appreciated!

Thank you

 

[runekock]

@Game-R
OpenGapps is designed to add GApps to a rom without it, not remove functions from a rom that included GApps from the start.

It's likely that OpenGapps makes a mess of the roms included GApps, because files are stored in different places. Don't do this.

Instead, you should research ways to de-bloat your rom. To some extent, you can delete apps by just deleting their files from the system partition. But it will be a trial and error process to find what you can remove without breaking other things. Or go the simpler route: deactivate the apps in settings without removing them fully.

 

[ALTracer]

In before curiousrom!

Reported it to the team.

Any in between those working?

Edit: Also some logs of the bootloop and GApps install would be nice to help narrow it down.

Got some logs for you.

After trying to update open_gapps-arm64-11.0-super 20211112->20211204, my phone failed to boot. Reverting to 20211125 achieved successful boot, but apps are old (and Play Store offers updates).

Apparently Wellbeing now requires android.permission.REAL_GET_TASKS and android.permission.START_TASKS_FROM_RECENTS.

Regarding @curiousrom 's suggestion. Can your team at least try your biggest arm64 `super` packages on some Android-capable Raspberry Pi 3/4 before rolling them out into production? Why did the script detecting permissions miss this?

Phone: santoni 3/32
ROM: LineageOS 18.1 20211111 mi-msm8937 landtoni unofficial by 0xCAFEBABE (nevermind the raven fingerprint).

 

[curiousrom]

@Nezorflame - Please remove the broken builds from the server ASAP!

Oh My Gosh, the bootloop was reported 48 hours ago in this thread & on Telegram and hundreds of users keep on downloading the broken builds, wasting their time & posting about it.

A OnePlus 7T + LineageOS 18.1 reported it here in the LOS subreddit and @haggertk who is one of the 9 Lineage Project director posted in it:

"Opengapps is perennially broken. You can play whack-a-mole and start picking older and older packages until you find a non-broken one, or use MTG, which is actually tested, instead."

This is so bad for the Open GApps Project's reputation.

This is a draft and the commit is not merged yet but LineageOS is about to add a warning against Open GApps in it's wiki: https://lineage.harryyoud.co.uk/318857/2/gapps.html :

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.
***

***

 

[ipdev]

@Nezorflame - Please remove the broken builds from the server ASAP!

Oh My Gosh, the bootloop was reported 48 hours ago in this thread & on Telegram and hundreds of users keep on downloading the broken builds, wasting their time & posting about it.

A OnePlus 7T + LineageOS 18.1 reported it here in the LOS subreddit and @haggertk who is one of the 9 Lineage Project director posted in it:

"Opengapps is perennially broken. You can play whack-a-mole and start picking older and older packages until you find a non-broken one, or use MTG, which is actually tested, instead."

This is so bad for the Open GApps Project's reputation.

This is a draft and the commit is not merged yet but LineageOS is about to add a warning against Open GApps in it's wiki: https://lineage.harryyoud.co.uk/318857/2/gapps.html :

View attachment 5475539


***

Interesting that they do not have a link to MindTheGapps for Android 10.
or test builds for Android 12

Why are they linking to OpenGApps nano packages?
I have not compared them recently.
The last time I checked MindTheGapps was closer to pico.

--

I would recommend you contact @hazzer (if he even is still on xda) and ask him to rewrite that warning a little nicer.

That kind of negativity is what makes everyone walk away from a project.
Unless that is the goal.
The You've been warned. part is salt in a wound and over the top.

Cheers.