Assigning to Bartosz as it's ARC related.

Thank you ... I just tested this today on the Google Pixelbook in version 65 Dev channel and it is still broken.  

Deleted: Screenshot 2018-01-12 at 10.25.37 AM.png 2.6 MB

	Screenshot 2018-01-12 at 10.25.37 AM.png 2.6 MB View Download

My understanding was that the host network shows up as WiFi in ARC++. Eric, Kevin, has this changed recently?

This is also interesting for a multi-network future: If we wire through Ethernet as Ethernet, some Android app may misclassify the connection as *inferior* to WiFi and e.g. not allow the user to download movies.

Wifi networks show up as TYPE_WIFI.  Everything else shows up as TYPE_ETHERNET.

I know this is a massive pain, but maybe Android on Chromebooks will provide a good justification to fix the mishandling of TYPE_ETHERNET in commonly-used apps?  The app bug can affect other scenarios too, like Android set-top boxes or wired tethering.

It's especially weird that this happens on a first party app, since I would expect that we really want to be checking the metered-connection bit before downloading a movie. This seems like a weird oversight for a Google app to make.

I'm not sure what the path forward is here; adding extra options to report a fake internet type to the container seems bad, but changing it so everything shows up as TYPE_WIFI doesn't seem right either. Also, by c#5 it seems like we misreport cellular-type connections as well, even though that should be pretty straightforward to report correctly.

It's up to you and Ben whether to report mobile connections as TYPE_CELLULAR...

One possible disadvantage is that apps might assume that cellular-related APIs are available if you do.  TYPE_ETHERNET is basically the lowest common denominator.

That's true, but if apps are using this instead of the metered bit to determine whether they should be downloading big files, then they might go ahead and do it over cellular (since it's "ethernet" to them) even if we report the metered bit correctly, which is something I think we really want to avoid...

It's your call, but I think it's still important to fix the apps so that they respect the metered bit.  Otherwise they will do the wrong thing on tethered/inflight wifi.

I would also assume that in e.g. rural areas, it is common for wired ethernet to be connected to a metered uplink such as HughesNet.

+Abhishek as he has also been looking at this

I agree, I'm just saying this is probably going to be an issue on apps we can't fix (at least not directly) and if we can avoid bad experiences there we should. That might not really be feasible, though. :S

As android applications come to more workplaces we could run into issues as (from what I have seen in many different companies) most workers prefer to have their machine docked on an Ethernet connection in corporate environments to allow for external devices to be attached as well as network reliability.  If we are having issues with some of the tier one applications such as these with just downloading a movie we could have issues with other applications and network traffic while on Ethernet.  Being that I support all of the Chrome devices in our company at this time and administer the policies to them I get to see a lot of what people actually do, don't do, should do, and just simply can't do.  There has to either be some sort of change on the back end network to Make all traffic go through Ethernet while connected, or policies put in place for app developers to fix their apps to work as expected.  

+ David for visibility.

So, what happens on DownloadManager.Request ?

https://developer.android.com/reference/android/app/DownloadManager.Request.html#setAllowedNetworkTypes(int)

I'm trying to understand what we do here.

I suspect this might be related to b/62926617

^Yes it is related to the bug. I have discussed this with Hugo before and he suggested a hack in the N code to make my patch work (I have a patch solving the metered bit). According to him, this hack wouldn't be required in master so I am conflicted as to whether we should change framework just for us.

Triage nag: This Chrome OS bug has an owner but no component. Please add a component so that this can be tracked by the relevant team.

Is this still relevant?

Yes this is still relevant.  Has this been fixed in any version yet?