Deploying to emulator (or to device via USB) doesn't honor "Required permissions" list in AndroidManifest.xml

[knocte]

Steps to Reproduce

1. Develop your XamarinAndroid app that accesses some service on the internet, e.g. by instantiating a System.Net.Sockets.TcpClient object.
2. Create .APK file for it (note: in this step, developer is an Android noob so he doesn't mark any permissions on the AndroidManifest.xml section of the project options).
3. Copy the .APK file to your phone's SD card.
4. Use the file explorer on your phone to install the .APK file.
5. Run the application inside your phone: it doesn't work (e.g. if the connection to the internet is done in a Task, app doesn't crash). Developer might be confused of why it doesn't work so then he decides to do something to debug it:
6. Run the application it on your emulator, or on your device deploying via USB with Visual Studio for Mac.

Current Behavior

App works fine when deployed this way (emulator or USB). Therefore the problem cannot be debugged/investigated by the developer.

Expected Behavior

It should fail to access to the internet because developer hasn't enabled INTERNET permission on the AndroidManifest.xml. An example of an exception that may happen is:

03-22 12:24:04.983 30369 30369 I MonoDroid: UNHANDLED EXCEPTION:
03-22 12:24:05.018 30369 30369 I MonoDroid: System.AggregateException: One or more errors occurred. ---> System.Net.Sockets.SocketException: Access denied
03-22 12:24:05.018 30369 30369 I MonoDroid:   at System.Net.Sockets.Socket..ctor (System.Net.Sockets.AddressFamily addressFamily, System.Net.Sockets.SocketType socketType, System.Net.Sockets.ProtocolType protocolType) [0x00069] in <6d05f74c602c4b558ceacaf5cfeb699b>:0 
03-22 12:24:05.018 30369 30369 I MonoDroid:   at System.Net.Sockets.TcpClient.initialize () [0x00000] in <6d05f74c602c4b558ceacaf5cfeb699b>:0 
03-22 12:24:05.018 30369 30369 I MonoDroid:   at System.Net.Sockets.TcpClient..ctor (System.Net.Sockets.AddressFamily family) [0x00046] in <6d05f74c602c4b558ceacaf5cfeb699b>:0 
03-22 12:24:05.018 30369 30369 I MonoDroid:   at System.Net.Sockets.TcpClient..ctor () [0x00000] in <6d05f74c602c4b558ceacaf5cfeb699b>:0 

Version Information

Visual Studio Community 2017 for Mac
Version 7.4 (build 1033)
Installation UUID: fd06ff65-69de-47ae-8b99-ddf257032b7c
Runtime:
	Mono 5.8.0.129 (2017-10/835a98d8559) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 508000129

NuGet
Version: 4.3.1.4445

.NET Core
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	2.0.5
	2.0.0
SDK: /usr/local/share/dotnet/sdk/2.1.4/Sdks
SDK Versions:
	2.1.4
	2.0.0
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/Sdks

Xamarin.Profiler
Version: 1.6.1
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Apple Developer Tools
Xcode 9.2 (13772)
Build 9C40b

Xamarin.Mac
Version: 4.2.0.20 (Visual Studio Community)

Xamarin.iOS
Version: 11.8.0.20 (Visual Studio Community)
Hash: 1c6f300e
Branch: d15-6
Build date: 2018-02-07 23:42:40-0500

Xamarin.Android
Version: 8.2.0.15 (Visual Studio Community)
Android SDK: /Users/andres/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		7.1 (API level 25)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 26.0.2
SDK Build Tools Version: 26.0.3

Java SDK: /usr
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Xamarin Inspector
Version: 1.4.0
Hash: b3f92f9
Branch: master
Build date: Fri, 19 Jan 2018 22:00:34 GMT
Client compatibility: 1

Build Information
Release ID: 704001033
Git revision: 053991068f3c88497d3e5cc52fe7fdf57c28b62f
Build date: 2018-02-28 05:02:28-05
Xamarin addins: cc3283953e0af0b8bfab1bdfdf847d9e403c4606
Build lane: monodevelop-lion-d15-6

Operating System
Mac OS X 10.13.1
Darwin 17.2.0 Darwin Kernel Version 17.2.0
    Fri Sep 29 18:27:05 PDT 2017
    root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64

Enabled user installed addins
Internet of Things (IoT) development (Preview) 7.1

Log File

N/A

[atsushieno]

IIRC runtime permissions are triggered only through Java API. So this behavior at least matches general expectation from Android native developer's point of view.

[knocte]

IIRC runtime permissions are triggered only through Java API. So this behavior at least matches general expectation from Android native developer's point of view.

Then it feels we could become better than Android Studio here? :)

Or at least present a dialog the first time the dev debugs the app, asking him to grant all permissions for the development session, or mimic the ones that will be present at APK-runtime time.

[atsushieno]

Ideas are easy, but designing and implementing them is not. There is no suggestion on the actual behaviors here. Implementing something overcomplicated on top of NDK, outside Android framework, by ourselves, does not sound great. Developers will hate immature hacks offered by Xamarin.Android.

It is NOT about the IDEs. Android Studio nor Visual Studio is relevant.

[atsushieno]

Developers want to reproduce what the app actually causes. Permission states and their successes/failures are one of the big things they want to replicate. "Grant all permissions by default" does not seem to be a great idea to me.

[knocte]

Developers want to reproduce what the app actually causes. Permission states and their successes/failures are one of the big things they want to replicate. "Grant all permissions by default" does not seem to be a great idea to me.

Atsushi, I completely agree with what you said here, which is exactly the reason I reported this bug. I think you have misinterpreted it in the opposite meaning. It's granting all permissions by default at the moment.

[knocte]

(Note that the exception posted is in the "Expected behaviour", not in the "Current behaviour".)

[atsushieno]

Whoa. Yeah I'm sorry, I misread. I believe that's wrong behavior. I am surprised to know that we accept anything by default. AFAIK we do need INTERNET permission for debugger connections but not any further (there might be additional permissions requirement after I got to know about them).

We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

[knocte]

It would be no longer relevant if it had been fixed?