On Android M+, this seems to have been moved under data usage.  It's the only place we could find this setting, anyway.

(For some other apps, that is.  Many others we checked don't set up this link.)

[Adding some folks because the CL requires exporting the Preferences Activity]

Carrying discussion back from the code review:

marcin@ is trying to make it so that clicking on the grayed out "App settings" takes you to Chrome's settings page (see attached image).  Problematically, this means that we'll need to export that (currently unexported) Activity to be in line with Android's framework, as specified here:
https://developer.android.com/guide/topics/manifest/activity-element.html#exported

It's kind of a fluke that intent filter works without the Activity being exported; link to the internal thread asking about this behavior:
https://groups.google.com/a/google.com/forum/#!topic/android-chatty-eng/BMiFz6RtpgU

Is it worth exporting the Activity to enable this button?  Doing so means that any external apps will be able to send users into Chrome's settings page.  I guess there's some security risk there because our settings page doesn't say anything about it being Chrome's (unless you're not signed in) (see second and third screenshots).

Deleted: 7325634736703762137-account_id=1.png 95.1 KB

	7325634736703762137-account_id=1.png 95.1 KB View Download

Deleted: 383329594958887877-account_id=1.png 106 KB

	383329594958887877-account_id=1.png 106 KB View Download

Deleted: 4210737309266847848-account_id=1.png 115 KB

	4210737309266847848-account_id=1.png 115 KB View Download

We go out of our way to make sure Preferences is not exported.  If we are forced to export this for this feature, then I'd quickly say we aren't going to do that (without some deep exploration on what would it take to harden our preferences activity).

https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/preferences/Preferences.java?q=Preferences.java&sq=package:chromium&l=233

So... the last email on the android thread is pretty final:

"""
Dan, it's a bug to keep the activity exported="false" if it's being made the official entry point for the MANAGE_NETWORK_USAGE mechanism.  The CL which adds that intent-filter should also remove the exported="false" attribute.  If you feel this particular activity should not be externally launchable in general, then it is not suitable to be the public entry point for that UX and you've got more work to do.  :)

More generally: it is an app bug for an activity to both have an <intent-filter> and to be declared non-exported.  The two concepts are contradictory.

(As to why it appears to work: it will work only when you access it via the Settings app.  That app runs as the system uid, and things running as the system have the ability to start any activity regardless of exported status.  However, by declaring an intent-filter you have inherently made the activity visible to all apps: that is a public declaration.  Any other app will believe it can do so based on your app's publication of the intent filter, except you'll then crash that other app because your exported="false" declaration metaphorically yanks the rug out from under them when they do so.)
"""

If we're not allowed to export our Activity because of the security hole pointed out by Ted's comment, I think we're stuck.

"it's a bug to keep the activity exported="false" if it's being made the official entry point for the MANAGE_NETWORK_USAGE mechanism" (but it seems to work)

&

MANAGE_NETWORK_USAGE mechanism without exported="false" seems to be source of (potential) security issue.

Could you maybe discuss internally with Android team two things:

1. changing the way that "Get App Settings" work in Android (but we won't have compatibility with current apps then)

2. checking if there are any problems with current behavior (excluding fact, that two concepts are contradictory). if not, maybe this could be more described in docs (exception for MANAGE_NETWORK_USAGE will be left) and my CL without removing exported="false" could be applied.

Not sure I'll make any headway with #1 given that whatever changes they make will apply only to Android O+‒we unfortunately still have to support Jellybean and up.

Re #2:
Can you clarify which current behavior you're mentioning?

I think he mentioned why landing your original patch would be problematic near the end of his email, where setting the IntentFilter would advertise that other apps could open our preferences Activity (via Intent resolution), but the other app would then crash trying to launch it.  In general I'd avoid relying on undocumented behavior: Android has all-too-often changed things under the hood and broken behavior we've relied on (accidentally or otherwise), resulting in bugs that take a long while to track down.  This case in particular looks like behavior they could change on their end without affecting properly configured apps (which we wouldn't be).

Re #1: this feature could be potentially supported by us from O+, right ? If it will be supported by adding attribute (instead of intent-filter we will have attribute in the activity), we could add it and done!

Re #2: can we ask Android team for documenting current behavior(s) for this intent-filter and making this combination (exported="false" + intent-filter MANAGE_NETWORK_USAGE) documented ? 

I think, that it would be enough for adding info in docs, that it will allow only Settings for opening page:

https://developer.android.com/training/basics/network-ops/managing.html could contain exported="false" in the example(s) + short explanation.

We will have compatibility with current apps/APIs.

I think you're underestimating how difficult it is to add a new API to Android -- especially when they've got a valid mechanism already working for most developers.  I posted their response about why this combination of flags is invalid up in Comment #5; it's a happy coincidence that it works on stock, but it can't be guaranteed to work on flavors of Android that are munged by manufacturers.

At this point, if you still feel strongly about this, you could try filing an Android bug to get some traction.  Your CL introduces too many potential side-effects to land.

> At this point, if you still feel strongly about this, 
> you could try filing an Android bug to get some traction.

https://code.google.com/p/android/issues/detail?id=231565