Develop Reference

Android Nougat has different dp calculation? Button sizes changed after update

My Samsung Galaxy s7 just updated to Android Nougat 7.0 and I noticed some of the buttons are displayed differently. I happen to have another Galaxy s7 around which hasn't gone through the update yet (Marshmallow 6.0.1). I can see the difference in sizes very clearly:
Marshmallow:
Nougat:
The layout_height of that SHARE button is hard set to 44dp. Using Layout Inspector in Android Studio I can read that it resolves to 176px for Marshmallow and 132px for Nougat (same values for mMeasuredHeight). You can also see that the other part of the layout on the left remained the same (ignore the little thumb up icon).
Another example:
Marshmallow:
Nougat:
I'm using following styling for the buttons:
<style name="AppTheme.Button" parent="Widget.AppCompat.Button">
<item name="android:textSize">14sp</item>
<item name="android:textColor">#color/colorPrimaryDark</item>
<item name="android:backgroundTint" tools:targetApi="lollipop">#color/colorTextBrightPrimary</item>
<item name="backgroundTint" >#FFFFFF</item>
<item name="colorButtonNormal">#color/colorTextBrightPrimary</item>
</style>
<style name="AppTheme.Button.Accent" parent="AppTheme.Button">
<item name="android:textColor">#color/colorTextBrightPrimary</item>
<item name="android:backgroundTint" tools:targetApi="lollipop">#color/colorAccent</item>
<item name="backgroundTint" >#color/colorAccent</item>
<item name="colorButtonNormal">#color/colorAccent</item>
</style>
While the SHARE button is a custom view, extending AppCompatButton, the Google and Facebook auth buttons are just AppCompatButtons. In either way, they all looked different just before the update and nothing else was changed in code, nor on the device (text size and zoom are the same).
Any idea what's going on? How to ensure these layouts stay the same on various devices/OS'?

A drawable can have its own padding. In the case of a nine-patch PNG file, that's simply having transparent pixels outside of the actual non-transparent/resizing portion of the image. In the case of ShapeDrawable, you can directly declare padding in the XML. And so on. This may or may not show up as "padding" in tools like the Layout Inspector, as they focus on padding declared on widgets.
Since the previous background you were using had the problem, and the replacement background does not, my guess is that this sort of implicit padding is the problem.
You have two approaches for trying to deal with this:
The risky-but-simple approach is to try using negative padding on the button itself, in a res/values-v24/ variant of your style resources (or, optionally, use a consistent dimension resource in the style and vary the dimension values based on -v25 or not). You would have to tinker a bit to try to get values that "undo" the change. I call this "risky" as I haven't the foggiest notion how well Android respects negative padding.
The aggravating approach is to try to find the actual button background that you were using before, and see what changed about it. The drawables would be declared either in appcompat-v7's themes or the platform's themes, and the actual drawables themselves would then be defined either in appcompat-v7 or in the platform.

Styles and themes on values, values-v11 and values-v14 folders

I am currently working on my app to base its design on the Holo theme. Globally what I want to do is working but I am a little confused about the way that are working the folders values, values-v11 and values-v14.
So I know that:
values is targeting the API inferior to 11
values-v11 is targeting the API between 11 and 13
values-v14 is targeting the API superior to 13
At first I thought I had to specify for every folder all the styles needed for the app but then I realized a kind of inheritance system was in place.
My problem is that I am really confused and don't understand clearly how is working this inheritance between these 3 folders.
I did the following test in order to see the behavior on my phone (running on Android 4.0, so the folder values-v14 should be the one loaded):
In values I have a style to set in blue the text color:
<style name="TextMedium" parent="#android:style/TextAppearance.Medium">
<item name="android:textColor">#color/Blue</item>
In values-v11 I have a style to set in white the text color:
<style name="TextMedium" parent="#android:style/TextAppearance.Medium">
<item name="android:textColor">#color/White</item>
In values-v14 I have a style to set in red the text color:
<style name="TextMedium" parent="#android:style/TextAppearance.Medium">
<item name="android:textColor">#color/Red</item>
For the first case above (every folder with a different color), the color loaded on my text is red, meaning the values-v14 folder gets the priority.
Then if I comment out the red style from the values-v14 folder, the text becomes white. Does that mean that the system will take the style in the values-v11 folder even if the device is targeting the values-v14 folder? I thought it would maybe use the values folder by default but not values-v11.
More generally, my question is, are these 3 folders working as parent and child?
Meaning that:
If the device is running on a API version > 13, the system will load values-v14 then values-v11 and finally values.
If the device is running on a API between 11 and 13, the system will load values-v11 and then values.
If the device is running on a API version < 11, the system will load only values.
If it is indeed the way it is working, does it make sense then to setup the maximum of styles in the parent folder values and add only specific ones in v11 or v14?
Sorry for the long question, I hope it is clear, this themes/styles system is only described briefly in the Android guide and it is difficult to find information on how it works...
Thanks for your help!

More generally, my question is, are these 3 folders working as parent
and child?
Those folders work with a "most specific" matching system meaning it will match the closest(lower) API level values folder:
values-v14 targets APIs >= 14(it will not be selected at all for versions below 14)
values-v11 targets APIs between(and including) 11 and 13 if values-v14 is present otherwise it will match every version starting with 11 and above((it will not be selected at all for versions below 11))
values is the default folder and it will be the last to be matched, covering other APIs levels not covered by another values-xx folder. You should always(as with all resources folders) have this folder in your app
If it is indeed the way it is working, does it make sense then to
setup the maximum of styles in the parent folder values and add only
specific ones in v11 or v14?
Yes, this is how the Android project template is built(when you use Create new project...), it actually tells you to use the values-xx folders for customization(different look, use of newer styles, attributes):
<!-- in the styles.xml from the v-14 values folder: -->
<!-- API 14 theme customizations can go here. -->

Android get an other style after adding value's folders

I have an application, that need to run in different size devices
For this, I added the next folders: res/values-normal and res/values-large.
Everything works fine except the application style was modified.
For example the Spinner was like the Model1 and after adding the folders it became like the Model2
http://postimg.org/image/cf3qa2oqd/
If I remove these folders, all returns as before (Model1).
Thanks,
NB: I was not able to add the image here.

the solution is:
change the Application Theme in the Style file
<style name="AppBaseTheme" parent="android:Theme.Holo">
it works fine.

Weird behaviour with drawables color in Android 4.0 or above

I have a strange problem with android resources. I have app created on Android 2.2 (android:minSdkVersion="8"). The application works fine.
When I installed app on for example Android 4.0, the application works fine, however at first run some resources are changed.
For example, I have drawable color named primary_color which refers to #FFFFFF html color. After installation, the system renders black color instead of white. In some cases #android:color/white renders black color.
Force closing app and restart app solving this problem.
Please help me to solve this issue.

This is caused by a bug in Android versions 4.0 to 4.1.3, I have been testing a similar problem with drawables turning to black only on devices with these versions, it is not present in devices with android version > 4.2.
I'm sure you noticed in your own research but it does not seem to be documented properly and there is no official solution but I can provide a few workarounds:
1) Turn off hardware acceleration, I used a different solution for my problem but this has been known to resolve some issues with images in the above mentioned Android versions. If you want hardware acceleration on for your application you can disable it for the problem activity by adding this to the activity declaration in your manifest.
<activity
android:name="activityName"
android:hardwareAccelerated="false"/>
2) For a solution specific to your example try setting the color to #android:color/transparent, this resolved my issue where I needed a background drawable to remain white.
3) Refer here: http://code.google.com/p/android/issues/detail?id=34619 to see a similar, documented bug and some of those solutions may work for your issue as well.
HTH

I came across the exact same problem!
I had this on colors.xml
<resources>
<color name="white">#ffffffff</color>
</resources>
And on styles.xml
<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
<item name="android:windowBackground">#color/white</item>
</style>
The problem was that when using fragment(which contains a ListView) inside an activity the ListView shows white color as background(which is what I need) at first run but at second run the ListView background was black. The problem only existed on Android 4.0(I did not test on 4.1) but worked fine on Android 4.3, 4.4, 5 etc.
Turns out only white color had the problem, when colors other than white was used there was no black background issue!
So as I wanted a white background and I did not want to have overdraw of having multiple background so setting white as the windowBackground on styles.xml was important but at the same time it causes black background issues!
So as solution, I created another color which is not completely white but its white
<resources>
<color name="fakewhite">#fffefefe</color>
</resources>
And on styles.xml
<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
<item name="android:windowBackground">#color/fakewhite</item>
</style>
Hence, in short color #ffffffff gets converted to #00000000 for Views like ListView and I also notice this behaviour on ScrollView.
This may not be a perfect solution but it worked for me!

Use different icons with different Android SDK versions

I have icons for my Android menu. On Android 3+ I'm using a black ActionBar so the icons are white. However, on Android 2.x the menu is inherently white which means the icons are nearly invisible. How can I use different menu icons for different versions? I'm assuming I can do it using different drawable directories like res/drawable-mdpi-v11, but I'm wondering if there is another way so I don't have to create a bunch of different directories as I add versions or pixel densities.
EDIT: I put dark versions in res/drawable-mdpi and res/drawable-hdpi for use with Android 2.x and I put light versions in res/drawable-mdpi-v11 and res/drawable-hdpi-v11 for use with Android 3.x and higher, but my Android 2.1 (sdk 7) emulator is still showing the light version.
Any idea why?

You can Select a theme based on platform version, as outlined in the Styles and Themes dev guide. Define a style in your res/values/styles.xml like this:
<style name="ThemeSelector" parent="android:Theme.Light">
...
</style>
Then in a res/values-v11/ folder, select your theme (probably Holo, if you're dark)
<style name="ThemeSelector" parent="android:Theme.Holo">
...
</style>
Then add icons to that style. For instance, here's a snippet from the styles.xml file from the HoneycombGallery sample application.
<style name="AppTheme.Dark" parent="#android:style/Theme.Holo">
...
<item name="menuIconCamera">#drawable/ic_menu_camera_holo_dark</item>
<item name="menuIconToggle">#drawable/ic_menu_toggle_holo_dark</item>
<item name="menuIconShare">#drawable/ic_menu_share_holo_dark</item>
</style>
The bottom 3 elements are all icons in the drawable directories. You'll still need at least one folder per resolution-specific set of icons, but you can combine the light & dark icons into the same folder, but you won't have to have different folders of icons for each platform version. Also, you'll need to list them as references in the values/attrs.xml file, like this:
<resources>
<declare-styleable name="AppTheme">
<attr name="listDragShadowBackground" format="reference" />
<attr name="menuIconCamera" format="reference" />
<attr name="menuIconToggle" format="reference" />
<attr name="menuIconShare" format="reference" />
</declare-styleable>
</resources>
At which point you'll be able to refer to them within your layout XML using the "?attr/NameOfYourDrawable" dereference, like this:
<item android:id="#+id/menu_camera"
android:title="#string/camera"
android:icon="?attr/menuIconCamera"
android:showAsAction="ifRoom" />

Found on the android dev site: http://developer.android.com/guide/practices/ui_guidelines/icon_design_menu.html
Warning: Because these resources can change between platform versions, you should not reference these icons using the Android platform resource IDs (i.e. menu icons under android.R.drawable). If you want to use any icons or other internal drawable resources, you should store a local copy of those icons or drawables in your application resources, then reference the local copy from your application code. In that way, you can maintain control over the appearance of your icons, even if the system's copy changes. Note that the grid below is not intended to be complete.
/res/drawable-hdpi (for Android 2.2 and below)
/res/drawable-hdpi-v# (for Android 2.3 and above)
Have you also tried testing this on a 2.1+ phone and not an emulator? If you don't have a phone, try creating another AVD? I'm afraid that you're going to need the separate folders.
Hopefully this helps.