Closed chirayudesai closed 3 years ago
I agree. I think merging carriersettings-extractor would be a cleaner solution than committing xml output to the device repos. It would also mean faster updates of any changes in the CarrierSettings protobufs included in monthly images.
Currently (for Android 10), GrapheneOS uses the APNs converted from CarrierSettings, but keeps the carrier configs from AOSP. The carrier configs in CarrierSettings reference several apps which are not included in the naked configuration group. We could later revisit whether any of the converted carrier configs are useful.
With Android 11, Google has included a new repo which seems to do what carriersettings-extractor does in reverse, converting AOSP xml format to the CarrierSettings protobuf format: platform/tools/carrier_settings. So we can presumably use the Google-supplied protobuf definitions instead of those that I wrote.
Happy to help implement this. From a cursory glance, it looks like the sample APNs are now included by build/make/target/product/aosp_product.mk:
PRODUCT_COPY_FILES += \
device/sample/etc/apns-full-conf.xml:$(TARGET_COPY_OUT_PRODUCT)/etc/apns-conf.xml
PRODUCT_COPY_FILES
retains the first dest match, so we have to insert our generated apns-conf.xml into PRODUCT_COPY_FILES
before that line, before aosp_product.mk is included, or just overwrite the file manually. What's the proper way to do this in android-prepare-vendor?
Currently (for Android 10), GrapheneOS uses the APNs converted from CarrierSettings, but keeps the carrier configs from AOSP. The carrier configs in CarrierSettings reference several apps which are not included in the naked configuration group. We could later revisit whether any of the converted carrier configs are useful.
Some of these apps might have been included in the full config we had here previously.
With Android 11, Google has included a new repo which seems to do what carriersettings-extractor does in reverse, converting AOSP xml format to the CarrierSettings protobuf format: platform/tools/carrier_settings. So we can presumably use the Google-supplied protobuf definitions instead of those that I wrote.
Interesting, that should help.
Happy to help implement this. From a cursory glance, it looks like the sample APNs are now included by build/make/target/product/aosp_product.mk:
PRODUCT_COPY_FILES += \ device/sample/etc/apns-full-conf.xml:$(TARGET_COPY_OUT_PRODUCT)/etc/apns-conf.xml
PRODUCT_COPY_FILES
retains the first dest match, so we have to insert our generated apns-conf.xml intoPRODUCT_COPY_FILES
before that line, before aosp_product.mk is included, or just overwrite the file manually. What's the proper way to do this in android-prepare-vendor?
I can take a closer look later, but one quick solution that comes to mind is just writing a new carrier.mk / override.mk with the relevant line, and then having the downstream projects add it to the appropriate place in their device repos once. There could be a better way, but this should just work and sounds simple enough, and this becomes explicitly opt-in from this small change.
We need this done for GrapheneOS in the next few days or we're going to lose compatibility with the carrier support we gained through adding these configurations. We don't have time to wait for android-prepare-vendor to provide a new way of doing it. If we end up having to drop support for this in the initial release to the Stable channel in the next few days, that's a major issue, because users have become dependent on these carriers working. We can't block releases due to this though.
Could you ship the android10 commit?
If not, I didn't intend this to be a blocker, you can always continue shipping what you had, and then revert when this is done.
Above commit now copies apns-conf.xml
vendor.xml still remains, but that contains references to lots of proprietary apps making it hard to use for "naked" configurations.
The "full" configuration can likely handle it fine though.
vendor.xml
is now implemented by https://github.com/AOSPAlliance/android-prepare-vendor/pull/65
I think we can close this now, vendor.xml
support has been implemented.
I think it makes to have it done here, since we already have the factory images and the CarrierSettings app / protobufs.
Also makes it easier to deal with licensing, everything proprietary in one place.
For #15 this'll be fine, upstream includes the app / .pb directly, and we can just do it in a separate script to make it easier to add it here right now and migrate later as needed.
@daradib @thestinger thoughts?