Closed thestinger closed 6 years ago
Indeed there quite a few additional build vendor properties that are missing. Most of them seem meaningless, although I've not carefully reviewed all of them. Have you noticed any broken functionalities that might be related to them (maybe the DRM stuff)?
Here is the diff I have when building from AOSP
$ diff -u vendor/build.prop /fast-datavault/aosp_prod/out_release_Linux_8.0.0_r3/aosp_prod/target/product/sailfish/vendor/build.prop
--- vendor/build.prop 2009-01-01 10:00:00.000000000 +0200
+++ /fast-datavault/aosp_prod/out_release_Linux_8.0.0_r3/aosp_prod/target/product/sailfish/vendor/build.prop 2017-09-11 23:28:25.050027427 +0300
@@ -1,7 +1,7 @@
-ro.vendor.build.date=Thu Aug 17 20:24:24 UTC 2017
-ro.vendor.build.date.utc=1503001464
-ro.vendor.build.fingerprint=google/sailfish/sailfish:8.0.0/OPR6.170623.012/4283428:user/release-keys
+ro.vendor.build.date=Mon Sep 11 23:27:53 EEST 2017
+ro.vendor.build.date.utc=1505161673
+ro.vendor.build.fingerprint=Android/aosp_sailfish/sailfish:8.0.0/OPR6.170623.012/anesti09112327:user/test-keys
# begin build properties
# autogenerated by vendor_buildinfo.sh
ro.product.board=sailfish
@@ -10,7 +10,12 @@
#
# ADDITIONAL VENDOR BUILD PROPERTIES
#
-ro.control_privapp_permissions=enforce
+keyguard.no_require_sim=true
+ro.com.android.dataroaming=true
+ro.config.ringtone=Ring_Synth_04.ogg
+ro.config.notification_sound=pixiedust.ogg
+ro.carrier=unknown
+ro.config.alarm_alert=Alarm_Classic.ogg
dalvik.vm.heapgrowthlimit=256m
ro.telephony.default_cdma_sub=0
dalvik.vm.heapstartsize=8m
@@ -84,30 +89,3 @@
ro.hwui.path_cache_size=16
ro.hardware.egl=adreno
ro.hardware.fingerprint=fpc
-ro.config.ringtone=Zen.ogg
-ro.config.notification_sound=Chime.ogg
-ro.config.alarm_alert=Flow.ogg
-ro.com.android.dataroaming=false
-ro.url.legal=http://www.google.com/intl/%s/mobile/android/basic/phone-legal.html
-ro.url.legal.android_privacy=http://www.google.com/intl/%s/mobile/android/basic/privacy.html
-ro.com.google.clientidbase=android-google
-ro.carrier=unknown
-ro.error.receiver.system.apps=com.google.android.gms
-ro.setupwizard.enterprise_mode=1
-ro.atrace.core.services=com.google.android.gms,com.google.android.gms.ui,com.google.android.gms.persistent
-ro.retaildemo.video_path=/data/preloads/demo/retail_demo.mp4
-ro.com.android.prov_mobiledata=false
-keyguard.no_require_sim=true
-drm.service.enabled=true
-media.mediadrmservice.enable=true
-ro.setupwizard.rotation_locked=true
-ro.facelock.black_timeout=700
-ro.facelock.det_timeout=2500
-ro.facelock.rec_timeout=3500
-ro.facelock.est_max_time=600
-ro.wallpapers_loc_request_suw=true
-ro.opa.eligible_device=true
-ro.storage_manager.enabled=true
-ro.com.google.ime.theme_id=5
-ro.boot.vendor.overlay.theme=com.google.android.theme.pixel
-
ro.control_privapp_permissions=enforce should be set but fixes are required to the AOSP whitelists before it can work.
https://source.android.com/devices/tech/config/perms-whitelist
Here are the fixes I needed:
Could be done here by overriding that whitelist with a fixed one, or providing another and just ignoring the broken entries there.
The DRM stuff should probably be added to the full configuration, but not naked. The ro.facelock.* ones are also needed for the full configuration.
ro.com.google.clientidbase=android-google, ro.error.receiver.system.apps=com.google.android.gms, ro.atrace.core.services=com.google.android.gms,com.google.android.gms.ui,com.google.android.gms.persistent, ro.setupwizard.rotation_locked=true, ro.setupwizard.enterprise_mode=1 is all tied to Play Services and probably belongs in full too.
ro.com.google.ime.theme_id=5, ro.boot.vendor.overlay.theme=com.google.android.theme.pixel are tied to the theme stuff, and ro.com.google.ime.theme_id=5 is also probably tied to Gboard on top of that. I think those should be left out for now, AOSP + vendor overlay stuff might not be enough.
ro.opa.eligible_device=true should probably be set for full configuration. IIRC it enables Pixel specific stuff, originally it would have enabled Google Assistant but maybe that's always on now.
Not sure what ro.wallpapers_loc_request_suw=true is but there's no reference to it in AOSP so it's probably more Google Play configuration so I don't think any of those missing properties has relevance to the naked configuration.
ro.storage_manager.enabled=true probably belongs in full configuration too, but I think AOSP only has the infrastructure for that without an implementation and it shouldn't be enabled.
And there are definitely a bunch of difference for sounds, icons, etc. in stock compared to AOSP but I don't know if that can be considered device files or if it's considered part of Play.
It can be confirmed that this theme works with cmd overlay enable com.google.android.theme.pixel
. It probably doesn't make sense to enable it at least for the naked configuration though. It isn't complete without Google Keyboard for that ime theme part, etc.
Closing in favour of #97 since PixelThemeOverlay works when enabled via adb.
@anestisb BTW the rro one directly in the overlay/ directory gets overridden by the overlays set by the AOSP build, which is a good thing since using the stock ones with AOSP would be broken, but it means that their Google Play frameworks/base overlays aren't kept. It's easy to diff it with a build of the current AOSP + android-prepare-vendor overlays to see what is missing though. Most is Play related but some might not be.
Speaking about the rro package I think it's safer to always copy across bytecode files only when the corresponding local module is defined in the makefile. Otherwise things in problematic state might slip into the image if not replaced by AOSP.
I've added some defensive logic in https://github.com/anestisb/android-prepare-vendor/commit/9d95e5af30ea181a02c76182198e27bf9c4b0a4b
So far it doesn't really change anything, although it would be an indicator if more bytecode blobs are inserted under /vendor and require special handling like the Pixel theme overlays.
This isn't important but it should probably get included. There are also vendor build.prop properties tied to it too, but it may not make sense to set those. I'm not sure how much of this is still in system but not in AOSP. Might all be a proper theme now... no idea.