Draft idea:
We can make it as a client library of Device Service, by moving all codes of //tools/battor_agent into //services/device/public/cpp/tools/battor_agent, and let the client library access directly SerialDeviceEnumerator and SerialIoHandler hidden inside //services/device/serial/, instead of consuming mojo interfaces exposed by Device Service.

I think a strong reason to not make //tools/battor_agent as consumer of Device Service is that the standalone executable //tools/battor_agent CAN NOT connect to Device Service.

//tools/battor_agent is used both as a standalone executable and a library consumed by Chrome. I do not think it should be moved into the device service (yet). Please explain why it cannot connect to the device service? We should be able to support the concept of standalone executables other than Chrome connecting to or embedding various services.

I don't think the choices must either be "client of the device service" or
"inside the device service," but I agree that forcing battor_agent to be a
client is not an attractive option at this time (it is a redistributable
thing that should not need to depend on e.g. the existence of a standalone
service manager that we don't have yet.)

The serial code can just be library code in //components (for lack of a
better home), consumed by both battor_agent and the device service impl.
(This is assuming we want to delete //device, since almost everything else
there will move into service impls)

I think that we can leave //tools/battor_agent be until we've exposed //device/serial via the Device Service and transformed the serial extension API impl to be a customer of the Device Service. At that point things might be more clear, or at least we can zero in on this issue as the remaining issue relating to //device/serial.

Now both SerialDeviceEnumerator and SerialIoHandler interfaces are exposed from Device Service and serial extension API impl is consuming them.
serial extension API impl has no any dependency on //device/serial/ now, while serial_apitest.cc is still depending on a test serial io handler impl inside //device/serial described by  issue 757169 .

Maybe ken's suggestion is the best choice for now? Moving //device/serial/ into //components?
Or can we just hide //device/serial/ inside Device Service but make it visible outside only to //tools/battor_agent?

Let's leave //device/serial where it is but restrict visibility to //services/device and //tools/battor_agent.

Current state:

//device/serial is restricted to be visible only to 
    //services/device/serial
    //tools/battor_agent:battor_agent_lib.

//device/serial:test_support is restricted to be visible only to
    //tools/battor_agent:battor_agent_unittests

To expand on #1 a bit for whenever and whoever ends up eventually tackling this challenge:

In my thinking, it's not clear where the best cutpoint is for //tools/battor_agent as a C++ library: Should it be on the other side of the Device Service or should it itself be in the Device Service and the cutpoint be somewhere between it and its dependencies? The answer is non-obvious to me.

If we eventually decide to move it into the Device Service, I think it would be fine to still create a standalone executable out of that part of the Device Service internal impl as we do today. It would mean that we'd need to leave the existing impl as an internal "base layer" that didn't know about Mojo so that the standalone executable could use it directly, and then wrap that layer in the Mojo communication for use by the Device Service.

The BattOr code has been removed.