Skip to content

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

Closed
Closed
Deploying to emulator (or to device via USB) doesn't honor "Required permissions" list in AndroidManifest.xml#1441
Labels
Area: App+Library BuildIssues when building Library projects or Application projects.possibly-staleIssues that are potentially no longer relevant.

Description

@knocte
knocte
opened on Mar 19, 2018

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

Activity

  1. atsushieno commented on Mar 23, 2018

    @atsushieno
    atsushieno
    on Mar 23, 2018
    Contributor

    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.

  2. knocte commented on Mar 23, 2018

    @knocte
    knocte
    on Mar 23, 2018
    ContributorAuthor

    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.

  3. atsushieno commented on Mar 23, 2018

    @atsushieno
    atsushieno
    on Mar 23, 2018
    Contributor

    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.

  4. atsushieno commented on Mar 23, 2018

    @atsushieno
    atsushieno
    on Mar 23, 2018
    Contributor

    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.

  5. knocte commented on Mar 23, 2018

    @knocte
    knocte
    on Mar 23, 2018
    ContributorAuthor

    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.

  6. knocte commented on Mar 23, 2018

    @knocte
    knocte
    on Mar 23, 2018
    ContributorAuthor

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

  7. atsushieno commented on Mar 23, 2018

    @atsushieno
    atsushieno
    on Mar 23, 2018
    Contributor

    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).

  8. jpobst
    added
    Area: App+Library BuildIssues when building Library projects or Application projects.
    on Oct 18, 2022
  9. jonathanpeppers
    added
    possibly-staleIssues that are potentially no longer relevant.
    on Dec 13, 2022

  11. knocte commented on Dec 14, 2022

    @knocte
    knocte
    on Dec 14, 2022
    ContributorAuthor

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

  12. ghost removed
    possibly-staleIssues that are potentially no longer relevant.
    on Dec 14, 2022
  13. ghost added
    need-attentionA xamarin-android contributor needs to review
    on Dec 14, 2022
  14. jpobst
    removed
    need-attentionA xamarin-android contributor needs to review
    on May 2, 2024
  15. jonathanpeppers
    added
    possibly-staleIssues that are potentially no longer relevant.
    on May 8, 2026

  16. dotnet-policy-service commented on May 8, 2026

    @dotnet-policy-service
    dotnet-policy-servicebot
    on May 8, 2026 – with Dotnet Policy Service

    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.

  17. dotnet-policy-service commented on May 22, 2026

    @dotnet-policy-service
    dotnet-policy-servicebot
    on May 22, 2026 – with Dotnet Policy Service

    This issue will now be closed since it had been marked "possibly-stale" but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

  18. dotnet-policy-service
    closed this as completedon May 22, 2026
  19. jonathanpeppers
    added a commit that references this issue on Jun 16, 2026

    Bump to dotnet/java-interop@6820a9cb (#11622)

    a2dfe8c
  20. github-actions
    locked and limited conversation to collaborators on Jun 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area: App+Library BuildIssues when building Library projects or Application projects.possibly-staleIssues that are potentially no longer relevant.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions