Iodé 7.3 build for Google tablet (tangorpro) fails

[petefoth]

@Lakrimar

So, if I understand you correctly, the latest v7 sources *do not build ‘out of the box’? It is necessary to create new certificates borfore the bold can succeed?

Yes, I needed to create the certificates on my own. I’m not quite sure if the certificates created by the container should be used within the lineage-priv folder. When I remember well it does not create this folder on its own. I think this are different ones. Maybe it is related to the “user” build and/or the preparation for the locked bootloader later on.

My userdebug 7.3 builds are working “out of the box”, with no changes needed to vertificate handling (or anything else). So may well be jus an issue with user builds

[Lakrimar]

I guess this is related to the certificates I use to sign the APKs shipped with Lineage/iodé in preparation to relock the bootloader. It is described in the Lineage wiki Signing Builds | LineageOS Wiki. I was thinking of giving it a try with completely new certificates for the APKs - maybe Bluetooth is working then again.

[petefoth]

@Lakrimar

I was thinking of giving it a try with completely new certificates for the APKs - maybe Bluetooth is working then again.

I had to do some spells to get Bluetooth working with Lineage 23.2. I’ll check tomorrow when I’m at my computer

[petefoth]

@petefoth

I had to do some spells to get Bluetooth working with Lineage 23.2. I’ll check tomorrow when I’m at my computer

OK. This was the issue that we had: Fix BT signing keys in 23.2 · Issue #858 · lineageos4microg/docker-lineage-cicd · GitHub

The fix was to change this line in our main build script to add the following three lines to `vendor/lineage/config/common.mk: (previously, it just added the first two lines)

PRODUCT_DEFAULT_DEV_CERTIFICATE := user-keys/releasekey
PRODUCT_OTA_PUBLIC_KEYS := user-keys/releasekey
PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES := $(dir $(PRODUCT_DEFAULT_DEV_CERTIFICATE))

[Lakrimar]

@petefoth

The fix was to change this line in our main build script to add the following three lines to ``vendor/lineage/config/common.mk`: (previously, it just added the first two lines)

PRODUCT_DEFAULT_DEV_CERTIFICATE := user-keys/releasekey
PRODUCT_OTA_PUBLIC_KEYS := user-keys/releasekey
PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES := $(dir $(PRODUCT_DEFAULT_DEV_CERTIFICATE))

Thanks a lot. I will give it a try this afternoon. My build yesterday with new certificates only wasn’t fixing the issue obviously.

[Lakrimar]

@petefoth

OK. This was the issue that we had: Fix BT signing keys in 23.2 · Issue #858 · lineageos4microg/docker-lineage-cicd · GitHub

Thanks a lot for the hint - it helped to analyse the issue after building it again.

I had the problem that the common.mk file is tampered all the time and the 3rd line is missing. Therefore I created a before.sh userscript which adds it again. Hope, that the Prepare build environment step does not use the common.mk settings as at this time it isn’t set yet. I also pulled the last version of the image. But I use the “pf-build-iodeOS” tag.

Unfortunately Bluetooth still refuses to work but I see the same error message as you described in your link. So it should be somehow related to this…

[petefoth]

@Lakrimar

Unfortunately Bluetooth still refuses to work but I see the same error message as you described in your link. So it should be somehow related to this…

It took me a while to get the fix right. The key fix seems to be as described in this comment

As I understand it, the variable PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES must contain exactly the value $(dir $(PRODUCT_DEFAULT_DEV_CERTIFICATE)) – see here and here.

I changed our shell script to the following:

  if [ "$android_version_major" -ge "10" ]; then
    sed -i "1s;^;PRODUCT_DEFAULT_DEV_CERTIFICATE := user-keys/releasekey\nPRODUCT_OTA_PUBLIC_KEYS := user-keys/releasekey\nPRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES := \$(dir \$(PRODUCT_DEFAULT_DEV_CERTIFICATE))\n\n;" "vendor/$vendor/config/common.mk"
  fi

which modified the file to read as I posted above. That finally allowed Bluetooth to work

[petefoth]

@Lakrimar

Hope, that the Prepare build environment step does not use the common.mk settings as at this time it isn’t set yet. I also pulled the last version of the image. But I use the “pf-build-iodeOS” tag.

Ah - that may be a problem: the needed change has not yet been merged to that branch. And as I use that branch for my iodé builds, I huess my 7,3 builds are also likely to be broken. I will test and see if I need to pull my recent 7.3 builds and re-do them with the fix

[petefoth]

@petefoth

Ah - that may be a problem: the needed change has not yet been merged to that branch. And as I use that branch for my iodé builds, I huess my 7,3 builds are also likely to be broken. I will test and see if I need to pull my recent 7.3 builds and re-do them with the fix

No that’s not a problem for our builds. Tested with 7.3 build for pdx357 and BT works fine, even though the config/common.mk does not have does not have the `PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES` line.

So it seems that BT is working in our unofficial 7.3 userdebug builds without the change. I can’t think of anything else to suggest - sorry!

[rik]

@petefoth thanks for the heads up, sorry I didn’t reply earlier but my unofficial v7.3 for cheetah that I installed last week doesn’t have any bluetooth issues, as you now confirmed.

But for you or @Lakrimar can you give a quick check if OpenEUICC is installed on any of your unofficial iodéOS builds? I don’t see it on cheetah and still have the Google SIM Manager? If not a quick response I can move this to a new thread.

[Lakrimar]

@petefoth

It took me a while to get the fix right. The key fix seems to be as described in this comment

I have the issue open. It helps me to analyse the problem, eg. with logcat but also the locations of the PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES parameter.

@petefoth

I can’t think of anything else to suggest - sorry!

Don’t worry. Thanks a lot for your effort. Maybe it is related to the lineage-priv folder which I use for the Apex keys. Beside the com.* certificates it also contains the releasekey, testkey and bluetooth key - even though that are the same as in the keys folder configured as container volume. The interesting part is that the key.mk file in the lineage-priv folder also contains the parameter for PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES.

Therefore my idea was to 1. change the parameter in that file and if that not works, 2. copy the override certificates for the package signing to the container volume for keys and 3. get rid of the lineage-priv folder totally.

[Lakrimar]

@rik

But for you or @Lakrimar can you give a quick check if OpenEUICC is installed on any of your unofficial iodéOS builds? I don’t see it on cheetah and still have the Google SIM Manager? If not a quick response I can move this to a new thread.

I had a look on the tablet and the only EUICC related app I can find is com.google.euiccpixel.overlay.gs201. The Google Tablet does not have a cell modem and does not use a SIM at all so this function isn’t really used, right?

[rik]

@Lakrimar

The Google Tablet does not have a cell modem and does not use a SIM at all so this function isn’t really used, right?

Yes of course. Sorry I forgot I’ll check in with others.

[petefoth]

@rik

But for you or @Lakrimar can you give a quick check if OpenEUICC is installed on any of your unofficial iodéOS builds? I don’t see it on cheetah and still have the Google SIM Manager?

No sign of it on 7.3 for pdx235 . Google SIM Manager is present, and searching in Apps for euicc shows only

• jp.co.sony.mc.euiccmemoryrest
• org.lineageos.euicc
• org.lineageos.euicc.overlay.sony

[Lakrimar]

Today I took the time to try out several approaches to get bluetooth working again.
I tried following without success:

1. Within the lineage-priv folder located in src/vendor I changed the keys.mk to point to user-keys as in the common.mk in the config folder (kept sources via CLEAN_AFTER_BUILD=false)
2. I copied the generated override certificates com.android.... to the keys volume used by the container (kept sources via CLEAN_AFTER_BUILD=false)
3. I deleted the lineage-priv folder completely (kept sources via CLEAN_AFTER_BUILD=false)
4. Performed a complete new build with deleted folders from do_cleanup and with keys.mk settings and APEX certificates
5. Performed a complete new build with deleted folders from do_cleanup without keys.mk setings and without APEX certificates
6. Performed a complete new build with deleted folders from do_cleanup and own certificates without APEX

Only with the copied certificate from AOSP src/build/target/product/security to the container keys volume bluetooth is working again.

Maybe it is related to an individual subject as I changed the KEYS_SUBJECT variable accordingly instead of using the default values…

[rik]

Any thoughts on this @petefoth ^^^^^^^^ not sure if we need to do something at l4m?

[petefoth]

I think not: there are two l4m issues relating to this (#786 and #868), and they both refer to making user builds, which we don’t do. Making user builds is ‘out-of-scope’ for l4m, unless someone can provide a PR with changes that are tested to work with user builds and to not break our userdebug builds.

I did have to make some changes to get BlueTooth working in our l4m builds (see #858), but thta change wasn’t necessary for our (my?) iodéOS builds.

[Lakrimar]

@petefoth

I did have to make some changes to get BlueTooth working in our l4m builds (see #858), but thta change wasn’t necessary for our (my?) iodéOS builds.

As suggested by @petefoth I tried the new 7.4 build without the userscripts setting the PRODUCT_MAINLINE_BLUETOOTH_SEPOLICY_DEV_CERTIFICATES separately and bluetooth is still working. It seems it is more about the certificate subject which I’ve set individually instead of using the default generic one.