Search code examples
androidandroid-theme

How to extend API dependend theme entries in an existing theme?

In Android development I'm allowed to provide API depending resources. I've a custom theme which I would like to extend with two new entries for API 29 and higher as described here.

So the file/folder structure looks like that:

res
 - values
   - dark_theme.xml
   - light_theme.xml
 - values-v29
   - dark_theme.xml
   - light_theme.xml

How can I just extend (add items to the existing theme) the theme defined in values\dark_theme.xml and values\light_theme.xml in values-v29\dark_theme.xml and values\light_theme.xml?

Let's say I want to extend the light theme with the new options for "edge-to-edge" feature. How do I need to set up the theme so I don't need to copy all the values from the original theme to the theme in -v29 folder?

Content of values\light_theme.xml:

<resources>
  <style name="AppTheme_Light" parent="BaseAppTheme">
    <item name="colorPrimary">@color/primary</item>
    <item name="colorPrimaryDark">@color/primary_light</item>
    ...
  </style>
</resources>

How does the file need to look like to use the items already defined in the theme in values folder without coping the whole theme?

Content of values-29\light_theme.xml:

<style name="AppTheme_Light" parent="BaseAppTheme">
  
  ...How to ensure all the previous items defined in values\light_theme.xml are used here?
  
  <item name="android:navigationBarColor">@android:color/transparent</item>
  <item name="android:statusBarColor">@android:color/transparent</item>
</style>
Solution

  • Apparently it seems the way to go is to use the XML attribute

    tools:ignore="NewApi"

    from the tools namespace.

    So I used those lines in my case instead of copying my styles files:

    <style name="AppTheme_Light" parent="BaseAppTheme">
  
  ...
  
  <item name="android:navigationBarColor" tools:ignore="NewApi">@android:color/transparent</item>
  <item name="android:statusBarColor" tools:ignore="NewApi">@android:color/transparent</item>
</style>

    If this is good practice seems "to depend" because I hide possible incompatible widget attributes.