Add overlay for Motorola Moto G7 Play (channel) #182
Conversation
This adds a hardware overlay for the Motorola Moto G7 Play. The property values are taken directly from stock ROM. Properties which matched the AOSP default values got removed, as well as some brightness related properties which caused problems. The `config_wifi_dual_band_support` and `status_bar_height_portrait` properties got added to fix the supported wifi bands and set the status bar to the height of the notch. In `config_gpsParameters` the `XTRA_SERVER` properties got adjusted to use Xtra3 instead of Xtra2 files. The overlay works fine and has been tested on a device for over a week now without any overlay related issues so far.
| @@ -0,0 +1,144 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <resources> | |||
| <bool name="config_auto_attach_data_on_creation">false</bool> | |||
There was a problem hiding this comment.
There is no comment about it in frameworks-res' config.xml
In DcTracker.java, there is:
* For non DDS phone, mAutoAttachEnabled should be true because it may be detached
* automatically from network only because it's idle for too long. In this case, we should
* try setting up data call even if it's not attached for 2G or 3G networks. And doing so will
* trigger PS attach if possible.
So basically the question this answers is whether it always keeps/tries to keep a data connection open.
When this value is false, it DOES auto connect on sim with preferred data in 2g/3g. So actually, "false" seems to be what should be the reasonable default. AOSP has true by default except for mcc/mnc 311/480 and 310/004.
Anyway this sounds reasonable in a device overlay, even though I might want to do it by default.
| <resources> | ||
| <bool name="config_auto_attach_data_on_creation">false</bool> | ||
| <bool name="config_automatic_brightness_available">true</bool> | ||
| <bool name="config_bluetooth_le_peripheral_mode_supported">true</bool> |
There was a problem hiding this comment.
config.xml says
Boolean indicating if current platform supports BLE peripheral mode
However this is used nowhere in AOSP. You could say it is used by external apps, but it's in API's greylist, so latest apps aren't allowed to read it.
It's definitely hardware-specific, but sounds useless. But we'll keep it anyway.
| <bool name="config_auto_attach_data_on_creation">false</bool> | ||
| <bool name="config_automatic_brightness_available">true</bool> | ||
| <bool name="config_bluetooth_le_peripheral_mode_supported">true</bool> | ||
| <bool name="config_cellBroadcastAppLinks">true</bool> |
There was a problem hiding this comment.
config.xml says Set to true to add links to Cell Broadcast app from Settings and MMS app
This is self-explicit, except for people who don't know what Cell Broadcast is (it's not used here in France at least)
Cell Broadcast is a technology where states (or mobile operator sometimes) can send messages to every cellphone in an area.
This is clearly not hardware-specific, I guess it could be enabled by default as well?
There was a problem hiding this comment.
I agree, enabling it by default makes sense to me as well.
| <bool name="config_speed_up_audio_on_mt_calls">true</bool> | ||
| <bool name="config_supportSystemNavigationKeys">true</bool> | ||
| <bool name="config_suspendWhenScreenOffDueToProximity">true</bool> | ||
| <bool name="config_switch_phone_on_voice_reg_state_change">false</bool> |
There was a problem hiding this comment.
state changes. Voice radio tech change will always trigger an update of
phone object irrespective of this config
The description is pretty clear, though I don't see the use-case for this, checking the source code doesn't help. Default in aosp is true, so that's indeed a change.
I guess we'll keep it.
| <bool name="config_suspendWhenScreenOffDueToProximity">true</bool> | ||
| <bool name="config_switch_phone_on_voice_reg_state_change">false</bool> | ||
| <bool name="config_useDevInputEventForAudioJack">true</bool> | ||
| <bool name="config_use_sim_language_file">true</bool> |
There was a problem hiding this comment.
flag to indicate if EF LI/EF PL should be used for system language
sim-cards may contain a fail that says the preferred language of the user.
With this flag, the default language on setup-wizard is based on sim card.
AOSP has it false by default, I don't really understand why, I should probably set it to true by default.
To me this isn't hardware-specific.
There was a problem hiding this comment.
I noticed that while it defaults to false in AOSP it's set to true for many MCC's/MNC's. I'd remove it here now and take whatever AOSP or you set as default.
This adds a hardware overlay for the Motorola Moto G7 Play. The
property values are taken directly from stock ROM. Properties which
matched the AOSP default values got removed, as well as some brightness
related properties which caused problems.
The
config_wifi_dual_band_supportandstatus_bar_height_portraitproperties got added to fix the supported wifi bands and set
the status bar to the height of the notch.
In
config_gpsParameterstheXTRA_SERVERproperties got adjusted touse Xtra3 instead of Xtra2 files.
The overlay works fine and has been tested on a device for over a week
now without any overlay related issues so far.
Known issues for this device so far are:
brightness related settings caused some problems, I hope the upcoming stock
Android 10 update will clear some things up there)
Aside from these issues everything works fine.
I plan to add a wiki page for the device soon as well.
@phhusson: As just discussed I'm not sure if all of the properties are hardware related. I'd appreciate if you could comment on the properties which aren't, so I can remove them before we move on with this PR.