This PR fixes #888 by providing an option to customise the Aztec toolbar colors.

Changes

• Added multiple attributes to AztecToolbar:
  • toolbarBackgroundColor - to change the background color of the Aztec Toolbar.
  • toolbarBorderColor - to change the color of the divider above the Aztec toolbar.
  • toolbarIconNormalColor, toolbarIconHighlightColor, toolbarIconDisabledColor - to change the color of the Aztec toolbar button icons.

The third point from the above change took a lot longer than expected and is the reason for a lot of changes in this PR. To explain more clearly, vector assets are not supported below API 21 and since Aztec supports a minimum version of API 16, we needed to make changes to the project to accommodate this.

Changes added to support vector drawables for < API 21 devices

• Enable AndroidX vector support in the app by adding vectorDrawables.useSupportLibrary = true to aztec, app and wordpress-comments modules. This flag prevents the Android Gradle Plugin from generating PNG versions of the vector assets if the minSdkVersion is < 21.
• All versions of vectors (back to API 14 through AndroidX) support using theme attributes (e.g. ?attr/colorPrimary) to specify colors. I went with this approach to change the color of the tooolbar icons. So I modified all the vector drawables to use toolbarIconNormalColor, toolbarIconHighlightColor and toolbarIconDisabledColor. Then defined the attributes under AztecToolbarStyle. This style can be overridden in the calling app to change the colors.
• Removed all the backgrounds defined statically in xml file.
• Added the logic to load drawables with the correct theme in code using AppCompatResources.getDrawable and specifying the theme we need to use. In this case: AztecToolbarStyle. Example can be found here.
• Since we use selectors which are nested Drawables i.e. StateListDrawable containing multiple vectors (for normal state, highlighted state and disabled state), when we ask AppCompatResources to fetch the drawable, it will see the <selector> tag, shrug, and hand it to the platform to load. It therefore will not get a chance to load the nested <vector> so this will either fail (on API <21) or just fall back to the platform support. In order to fix this in lower version devices, I modified all the <selector> to use <animated-selector>.
• I also modified all instances of ContextCompat.getDrawable to use AppCompatResources.getDrawable (taking suggestion from this SO answer) since this was causing a crash issue in devices below API 21.

I know the PR file size looks big but most of the changes are modifying selector to animated-selector and changing the static colors defined in the drawables to use theme colors so I felt it shouldn't be a problem.

To test

1. Since this PR only makes changes to the styles, smoke testing the Aztec editor by selecting all the toolbar options should suffice.

• Testing in API 16, 21, 28 and 29 would be great since the change affects all supported API versions. Without making any modifications to the app activity, the Aztec toolbar should look and function exactly as before.
• Testing with advanced menu enabled/disabled in the toolbar would be great.

2. In order to test if changing the style from the calling app changes the toolbar colors, we need to override the AztecToolbarStyle in our app/styles.xml.
   • Add the following xml code in activity_main.xml and v17/activity_main.xml:

      aztec:toolbarBackgroundColor="@color/background"
      aztec:toolbarBorderColor="#E6E6E6"
     

   • Add the following style in our app/v21/styles.xml:

         <style name="AztecToolbarStyle">
                  <item name="advanced">false</item>
                  <item name="toolbarIconNormalColor">#595959</item>
                  <item name="toolbarIconHighlightColor">@color/almost_black</item>
                  <item name="toolbarIconDisabledColor">@color/grey_lighten_20</item>
         </style>
     

Screenshots

API 16 - Default view (before overriding styles)

. .

API 16 - Customised view (after overriding styles)

. .

API 19 - Default view (before overriding styles)

. .

API 19 - Customised view (after overriding styles)

. .

API 21 - Default view (before overriding styles)

. .

API 21 - Customised view (after overriding styles)

. .

API 23 - Default view (before overriding styles)

. .

API 23 - Customised view (after overriding styles)

. .

API 28 - Default view (before overriding styles)

. .

API 28 - Customised view (after overriding styles)

. .

API 29 - Default view (before overriding styles)

. .

API 29 - Customised view (after overriding styles)

. .

Make sure strings will be translated:

• If there are new strings that have to be translated, I have added them to the client's strings.xml as a part of the integration PR.