Note that when doing the code move, we'll need to put location_provider.h in //services/device/public/cpp/ in order to allow clients to implement that interface to override the system location provider.

Hi, Colin, is there issue track the "inject the URLRequestContextGetter and ApiKeyGetter" to ctor of DeviceService?  I think we should set it as blocker to this issue?

Or anyone (Hi, amoylan@ ?) already start working on it? If no, I'll do it. Just make sure no duplication work:)

This is indeed planned to happen as part of implementation of IP geolocation. Specifically in the fourth CL in the chain: crrev.com/c/754256

+renjieliu who is taking over shepherding these as I am on baby leave.

I suggest that rather than blocking this effort on that one, Ke He, if you get to the point where you're ready to host geolocation in the Device Service and the CL mentioned in c#13 isn't yet landed, you and Renjie coordinate to see who's closer to landing an addition of the injection code :).

Hi, Renjie, I'm going to work on "injecting URLRequestContextGetter and ApiKeyGetter" as Colin suggested. Now all the parallel works are done, Seems this injection is the only thing block us to move on.

Renjie, I found you just updated the 754256 one day ago, please let me know if that CL will be landed soon?

Hi Ke, that cl is currently blocked by ccrev.com/c/784533 which blocked by ccrev.com/c/788477, so if will be helpful if you can check in "injecting URLRequestContextGetter and ApiKeyGetter" :)

Thanks a lot!

Renjie, thanks! 
I cannot open the link of ccrev.com. But I think the "injecting URLRequestContextGetter and ApiKeyGetter" can be landed alone regardless of those blockers, right? 
If it is, I'll start to do it.

Yes, I think that can be landed alone :)

Those links should be "crrev.com".