locked
"Target Android version" project property is wrong RRS feed

  • Question

  • User15741 posted

    The drop-down list of SDK versions in Android project property Target Android version has an option that reads Automatic - use target framework version and if selected it removes the targetSdkVersion attribute from the manifest file.

    However, the Android documentation states that the absence of this property implies that the target is equal to the minSdkVersion attribute. This makes sense as the complied app contains no information about the target version against which it was built.

    Tuesday, August 21, 2018 2:08 PM

All replies

  • User12817 posted

    @RupertRawnsley We are working to make this scenario more clean on Visual Studio for Mac. We've already made changes in Visual Studio 2017 to prevent users from getting into an incompatible scenario using these "Automatic/Use Latest" behaviors. The following GitHub issue describes these scenarios:

    https://github.com/xamarin/xamarin-android/issues/1163

    The general guidance is to use explicit override values that match the following guideline:

    minSdkVersion <= targetSdkVersion <= compileSdkVersion(TargetFrameworkVersion)

    Tuesday, August 21, 2018 8:30 PM
  • User15741 posted

    @JonDouglas Great - thanks for the info.

    Wednesday, August 22, 2018 8:02 AM
  • User392 posted

    @JonDouglas @JonathanPryor @JamesMontemagno I am not sure this is related. But...

    I have my app Build properties page to specifically use 27. I have my manifest have a min of 21 and my target set to auto (which leaves the targetsdk in the manifest unspecified). I have had my manifest this way for years but have only changed the build properties page to continually specify newer SDK to build with as they are released.

    In order for me to submit my app to Google Play, I must add the target sdk specification in the manifest due to their new requirements. Therefore, I set the target sdk to 27. Now when I run my app, all of my colors are wrong, specifically the primary text color. I did not specifically set my text colors in code and relied on the theme to do it.

    So why is it that as soon as my target sdk in the manifest, it messes up my colors? If I remove the target sdk and go back to Auto in the manifest, my colors are restored to normal.

    Wednesday, October 31, 2018 6:34 PM
  • User12817 posted

    @ShawnCastrianni My best guess is that because there was not an explicit value set, that your application would run with the value of your minSdkVersion instead, which would mean that your targetSdkVersion at runtime would be 21 instead of the expected value of 27. Although I'm not sure about your color change, I would guess a theme or similar is being applied with the correct behavior of targetSdkVersion explicitly matching your TargetFrameworkVersion.

    Wednesday, October 31, 2018 6:40 PM
  • User392 posted

    @JonDouglas @JonathanPryor @JamesMontemagno This is very strange. I find Android Themes and styles very difficult to debug. Have you ever tried to figure out what the default color of a TextView is. You start in theme_material.xml and around 5 drilldowns later, you might find an actual color value, if you are lucky. It seems the best way to go for the future is to explicitly set everything instead of relying on the Theme.

    Anyway, I added some debug code to the top of my main activity's OnCreate:

            TypedArray ta = Theme.ObtainStyledAttributes(new int[] {
                Android.Resource.Attribute.TextColorPrimary
            });
            Color tcp = ta.GetColor(0, 123456);
            SetTheme(Resource.Style.MyMaterial);
            ta = Theme.ObtainStyledAttributes(new int[] {
                Android.Resource.Attribute.TextColorPrimary
            });
            tcp = ta.GetColor(0, 123456);
    

    This shows that before I programmatically set my Theme, the textcolorprimary is 243,243,243,255. After I set my Material theme, my textcolorprimary is 0,0,0,222. This matches my Theme.Material.Light correctly. However, when running against no specified targetSdkVersion, this primary text color used is ignored by the UI and White is used which is what I was used to all of these years.

    When I set my targetSdkVerion = 27, the above debug code behaves exactly the same (as it should), but now the UI seems to honor the primary text color and is blackish.

    So I said, maybe I have been taking advantage of a bug all of these years where I was getting white text (like I want), and the theme wasn't being honored. If setting targetSdkVersion = 27 causes the Theme to be honored, then the solution should simply be to change my theme to Theme.Material (and remove the .Light portion). Unfortunately, when I try that, even though the above debug code does change its behavior and the primary text color comes out whitish (good), the UI seems to ignore it and stays black.

    None of this makes any sense to me.

    PS: You might be wondering why I am programmatically setting my Theme in code. My answer is that I have been doing Xamarin for longer than most ( @JonathanPryor can attest to that). Back when I started, there was not an easy way to do an Android splash screen. Therefore, I set my default app theme to a custom theme with no action bar and a splash windowBackground image. And then change the theme to what I really want in my main activity with an actionbar. I have been using this method of splash screen for many years. Is it possible that setting a theme programmatically is causing my issues??

    Wednesday, October 31, 2018 8:38 PM
  • User12817 posted

    @ShawnCastrianni I would err on the side that because of the lack of an explicit targetSdkVersion in your case, that you were designing your application around the non-expected behavior without knowing it.

    We found similar developer cases where certain Android features would misbehave(Visually or functionally) due to the lack of the explicit targetSdkVersion in the AndroidManifest.xml file which controls at runtime what feature flags are enabled / forward compatibility. This is especially an issue for things like runtime permissions, PiP, and much more.

    If you have a sample project that can help us picture this situation, I believe we'd be able to help further. I'm not exactly sure what themes you have applied to your project and what they may be inheriting from.

    Wednesday, October 31, 2018 8:49 PM
  • User392 posted

    @JonDouglas @JonathanPryor @JamesMontemagno I found my issue. Even though I have been developing with Xamarin for longer than most, I am by no means fluent in Android. All of these years, I thought the theme was an application wide setting such that in my main activity when I called SetTheme programmatically, I thought it was setting the theme for the entire application. I didn't realize that each Activity can have its own Theme. Therefore, I never bothered to set an application wide default theme in my manifest. Therefore, the only activity that was using my custom MyMaterial theme was my Login activity (the main activity) since that is where I set the theme programmatically. All of my other activities were apparently picking up some kind of default. By not setting targetSdkVersion, it may have been picking up a minSdkVersion 21 default. After setting targetSdkVersion to 27, it was probably using a different default theme causing my colors to change. Combining this issue with me accidentally using Theme.Material.Light when I really wanted Theme.Material was the cause of all of my problems above.

    Therefore, my fix was to change custom MyMaterial theme to extend Theme.Material (instead of Theme.Material.Light) and to add an application wide default them in the manifest to MyMaterial. The Login activity overrides the theme to Theme.Splash and then changes it to MyMaterial programmatically to make the splash screen work.

    I think everything is good now. Thanks for listening.

    Wednesday, October 31, 2018 11:46 PM