Created attachment 23292 [details]
Example Android 7.0 Project
When targeting Android N 7.0 or newer CheckSelfPermission always returns Granted.
Steps to reproduce
1. Create an android project targeting 7.0 or newer add Xamarin.Android.Support.Compat.25.3.1\lib\MonoAndroid70\Xamarin.Android.Support.Compat.dll
2. Add AccessFineLocation to manifest
2. Deploy app to Android M or newer device
3. From device settings remove Location permission that was granted without asking - weird
4. Add line below to OnStart
var access = Android.Support.V4.Content.ContextCompat.CheckSelfPermission(this, Manifest.Permission.AccessFineLocation);
"access" is always stated as Granted. Since it states Granted the code doesn't know to ask for permission and location request never return. However if you request permission blindly, OnRequestPermissionsResult is fired with the correct response.
NOTE: ShouldShowRequestPermissionRationale also returns the incorrect value always being false.
NOTE: If you target M the behavior returns to normal and CheckSelfPermission returns the correct granted or denied.
See attached App2.zip
Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Installed Version: Professional
LightSwitch for Visual Studio 2015 00322-40000-00000-AA087
Microsoft LightSwitch for Visual Studio 2015
Microsoft Visual Studio Tools for Applications 2015 00322-40000-00000-AA087
Microsoft Visual Studio Tools for Applications 2015
Visual Basic 2015 00322-40000-00000-AA087
Microsoft Visual Basic 2015
Visual C# 2015 00322-40000-00000-AA087
Microsoft Visual C# 2015
Visual C++ 2015 00322-40000-00000-AA087
Microsoft Visual C++ 2015
Visual F# 2015 00322-40000-00000-AA087
Microsoft Visual F# 2015
Windows Phone SDK 8.0 - ENU 00322-40000-00000-AA087
Windows Phone SDK 8.0 - ENU
ASP.NET and Web Tools 2015.1 14.1.21111.0
ASP.NET and Web Tools 2015.1
ASP.NET Web Frameworks and Tools 2012.2 4.1.41102.0
For additional information, visit http://go.microsoft.com/fwlink/?LinkID=309563
ASP.NET Web Frameworks and Tools 2013 5.2.40314.0
For additional information, visit http://www.asp.net/
Azure App Service Tools v2.9.6 14.0.21111.0
Azure App Service Tools v2.9.6
Azure Data Lake Node 1.0
This package contains the Data Lake integration nodes for Server Explorer.
Azure Data Lake Tools for Visual Studio 2.2.5000.0
Microsoft Azure Data Lake Tools for Visual Studio
Common Azure Tools 1.8
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
Microsoft Data Factory Package
Extensions Monitor Extension 1.0
ExtensionsMonitor Visual Studio Extension Detailed Info
JetBrains ReSharper Ultimate 2017.1.3 Build 108.0.20170613.154143
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2017 JetBrains, Inc.
Merq 1.1.17-rc (cba4571)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.
Microsoft .NET Core Tools (Preview 2) 14.1.21111.0
Microsoft .NET Core Tools (Preview 2)
Microsoft Azure Data Factory Node Node 1.0
Azure Data Factory extension for Visual Studio Server Explorer.
Microsoft Azure Hive Query Language Service 2.2.5000.0
Language service for Hive query
Microsoft Azure Mobile Services Tools 1.4
Microsoft Azure Mobile Services Tools
Microsoft Azure Tools 2.7
Microsoft Azure Tools for Microsoft Visual Studio 2015 - v2.7.30818.1601
Microsoft Azure Tools 2.8
Microsoft Azure Tools for Microsoft Visual Studio 2015 - v2.8.40211.2
Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 2015 - v2.9.41104.6
Mono Debugging for Visual Studio Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.
NuGet Package Manager 3.5.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.
Office Developer Tools for Visual Studio 2015 ENU 14.0.23928
Microsoft Office Developer Tools for Visual Studio 2015 ENU
PreEmptive Analytics Visualizer 1.2
Microsoft Visual Studio extension to visualize aggregated summaries from the PreEmptive Analytics product.
SQL Server Analysis Services 13.0.1701.8
Microsoft SQL Server Analysis Services Designer
SQL Server Data Tools 14.0.61021.0
Microsoft SQL Server Data Tools
SQL Server Integration Services
Microsoft SQL Server Integration Services Designer
SQL Server Reporting Services 13.0.1701.8
Microsoft SQL Server Reporting Services Designers
SQLite & SQL Server Compact Toolbox 4.7
SQLite & SQL Server Compact Toolbox adds scripting, import, export, rename, query execution and much more to SQL Server Compact & SQLite Data Connections.
Hosting json editor into a tool window
TypeScript tools for Visual Studio
Visual Studio Tools for Apache Cordova Update 10
Visual Studio Tools for Apache Cordova
Workflow Manager Tools 1.0 1.0
This package contains the necessary Visual Studio integration components for Workflow Manager.
Xamarin 220.127.116.116 (fec6f88)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin.Android 18.104.22.168 (9dbc4c5)
Visual Studio extension to enable development for Xamarin.Android.
Xamarin.iOS 10.10.0.37 (ad35de4)
Visual Studio extension to enable development for Xamarin.iOS.
@Joe, I think the behavior is correct. Please consult https://developer.android.com/training/permissions/requesting.html - namely these paragraps:
If the device is running Android 5.1 or lower, or your app's target SDK is 22 or lower: If you list a dangerous permission in your manifest, the user has to grant the permission when they install the app; if they do not grant the permission, the system does not install the app at all.
If the device is running Android 6.0 or higher, and your app's target SDK is 23 or higher: The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running. The user can grant or deny each permission, and the app can continue to run with limited capabilities even if the user denies a permission request.
The sample app's lowest Android platform is API 16 which makes the app fall in the first category above, thus the API returns `granted` since all the permissions have been granted at the install time.
Created attachment 23311 [details]
IDE Application screen shot
Created attachment 23312 [details]
Manifest Screen Shot
To make sure we are seeing the same thing. In the App2 screen shots from the IDE its says the Target Framework is 7.1 and I thought it should compile for 7.1 but is not. So it looks like the IDE is showing the wrong Target or the Build is for the wrong target.
If you look at the AndroidManifest.xml it has only minSdkVersion="16" and so what would be the build behavior for this?
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="App2.App2" android:installLocation="auto" android:versionCode="1" android:versionName="1.0">
<uses-sdk android:minSdkVersion="16" />
You should use `<uses-sdk android:minSdkVersion="23" />` for the app to support runtime granting of permissions.
The screenshots in comments 2 and 3 show the correct information. Your target (highest supported) framework version is 7.1 but your lowest supported (corresponding to uses-sdk) is 4.1, API 16. This tells the OS that you expect your app to run on API 16 and not older and that you have dynamic checks in your code that allow you to make use of platform features up to version 7.1, API 25. The minimum of those versions applies in the two paragraphs I quoted in comment 1.
Hope that helps!
Why does targeting 23 work just fine?
<uses-sdk android:minSdkVersion="16" android:targetSdkVersion="23" />
If you read below, no where is it stated that targetSdkVersion can be omitted. So why is the IDE removing the targetSdkVersion?
WHAT IS THE BUILD BEHAVIOR IF targetSdkVersion IS OMITTED?
This is the SDK version number that the application is targeting.
This is the SDK version number that the application is targeting. It is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here. Specifying this version allows the platform to disable compatibility code that are not required or enable newer features that are not available to older applications. This may also be a string (such as "Donut") if this is built against a development branch, in which case minSdkVersion is also forced to be that string.
May be a string value, using '\\;' to escape characters such as '\\n' or '\\uxxxx' for a unicode character.
May be an integer value, such as "100".
This may also be a reference to a resource (in the form "@[package:]type:name") or theme attribute (in the form "?[package:][type:]name") containing a value of this type.
@Joe, we're investigating whether it is a build issue in our target files - a failure to put `targetSdkVersion` in the manifest in addition to/instead of `minSdkVersion' because absence of the former in presence of the latter uses the value of `minSdkVersion` as the target SDK which explains the default behavior you see. To work around it, set both versions (screenshots in comment 2 and comment 3) to explicit values.