One Socket, Four Jobs: What a 24/7 Phone Camera Gives Up to Stay Charged

Short answer: A phone has one USB socket, and a camera that runs around the clock has already spent it on power. Everything else you might want to plug in — a wired network adapter, an external disk, a better microphone, a debug cable — is asking for that same socket, and Android's own documentation says that in that arrangement the phone is the side supplying current rather than receiving it. Splitting hardware exists. Whether your particular handset cooperates with it is a per-device question Google explicitly declines to answer, and the test that decides it needs no purchase.

The one specification nobody writes down

Across this catalogue we have said the same thing dozens of times: keep it plugged in. It is sound advice and it is most of why a retired handset can hold down a job that a battery-powered gadget cannot. What none of those guides go on to say is that a phone has exactly one place to plug anything into, and that continuous power is a permanent tenant of it.

Every other capability people ask about arrives at the same connector and finds it occupied. Can I put it on a wire instead of the radio. Can I hang a large disk off it. Can I use a proper microphone. Can I leave a debug cable attached so I can look at logs. Those are four reasonable requests and they are all bids for one physical resource. No app can route around a connector that is already in use, and no update will add a second one.

This piece is about what actually competes for that socket, what the platform documentation says about each contender, and how to find out in a single sitting whether your handset can be persuaded to do two things at once.

What the phone becomes when you plug hardware into it

Android has two USB personalities, and which one you are in decides who pays for the electricity. From Google's connectivity overview:

"In USB host mode, the Android-powered device acts as the host. Examples of devices include digital cameras, keyboards, mice, and game controllers."

And then the sentence that matters for a device you are trying to keep charged:

"When the Android-powered device is in host mode, it acts as the USB host and powers the bus."

Read that against a camera phone. The instant you attach a network adapter or a disk, the phone stops being a thing that receives current and becomes a thing that hands it out. A setup whose entire premise is permanently plugged in has quietly reversed the direction of its own power.

The capability itself is not new:

"USB accessory and host modes are directly supported in Android 3.1 (API level 12) or newer platforms."

So this is not a question about how modern your handset is. It is a question about your handset in particular, and the documentation says so in as many words:

"Support for USB host and accessory modes are ultimately dependant on the device's hardware, regardless of platform level."

The spelling is Google's, and the sentence is the most useful one on the page. There is no published list of which phones do it. There is no screen in Settings that reports it. A given handset either does or does not, and the only party who ever knew was the manufacturer, who mostly did not say.

Job 1 — power, which is not negotiable

Nothing else in this article is a requirement. This one is. A camera that is awake for every hour of every day outruns any battery, which is why every guide on this site, and every competing guide, opens by telling you to plug it in. So treat power as the sitting tenant and everything below as an application to share the room.

Two consequences are easy to miss. The first is that unplugging to attach something starts a clock — a phone doing continuous capture does not have a comfortable reserve to spend on your experiment. The second is that most of the sharing hardware below asks the phone to negotiate power and data across the same connector at once. That is a materially different electrical arrangement to a plain charger, and it is precisely where per-device behaviour diverges.

Job 2 — a wired network

This is the request that comes up most, and the reasoning behind it is sound. Of all the permanently powered devices in an ordinary home — a television, a games console, a printer, a desktop — the phone is the only one with no documented way to join the network by cable.

Google does document Ethernet on Android. It documents it twice, and neither time for the thing in your hand.

The first is the tethering module, which describes the phone giving a connection away rather than taking one:

"The Tethering module shares an Android device's internet connection with other connected client devices, which can connect to tethering devices over Wi-Fi, USB, Bluetooth, or Ethernet."

Ethernet is in that sentence as an outbound path. The phone is the source, not the client.

The second is an Android Open Source Project page titled Configure internal Ethernet networks, and its opening line settles who it is for:

"Android Auto OS 13 and higher contains features allowing you to configure and manage Ethernet networks."

That is the automotive build of Android. The API it describes is called by an OEM's own networking application, and the worked example is a car with three onboard interfaces. It is a genuine Google page about configuring Ethernet on Android and it has nothing to do with a handset on a shelf. Checking which product a document belongs to before you lean on it is a habit worth keeping; this page is a good argument for it.

Now the consumer side. The Android Help page for changing network settings on a phone opens:

"You can change network settings like automatic connections, metered access, proxy settings, and more."

What follows is metered Wi-Fi, MAC addresses, Private DNS and a list of Wi-Fi preferences. The help topic that page sits inside carries twelve articles — Wi-Fi, hotspot and tethering, VPN, mobile plans, Quick Share, this page, smart home devices, Cloud Print migration, internet troubleshooting, file sharing with Windows, automatic connection to saved Wi-Fi and instant hotspots, and Thread. There is no Ethernet article in it.

So the honest position is this, and I would rather state it than dress it up. A USB network adapter is a USB device. USB host support is per-handset by Google's own statement. Whether Android then routes ordinary traffic over that interface on your specific phone is not something anyone has published, for any list of phones. It is cheap to test and impossible to look up.

The related question — why a phone can be recording perfectly and still be slow to answer on the network it is already on — is a different mechanism entirely, and it lives in the piece on Wi-Fi power save and WifiLock.

Job 3 — an external disk

A camera fills storage, and hanging a disk off the socket looks like the obvious fix. It collides with power in exactly the same way, and it adds a wrinkle: a large disk is a heavier electrical load on a bus the phone is being asked to supply. A bus-powered drive and a permanently-charging phone are competing for the same watts through the same connector, which is a hardware problem rather than a configuration one.

Before buying anything for this, it is worth reading the retention arithmetic — a lot of setups that feel storage-bound are really recording at settings nobody chose deliberately, and the cheapest disk is the one you did not need.

Job 4 — the debug cable, and Google's own way around it

The platform's own authors run into this constraint and resolve it exactly the way you will have to. From the debug notes on the same USB page:

"You can still access adb over a network connection."

That is the shape of the whole problem in one sentence, written by people who hit it first. Once USB hardware is attached, the USB link to a computer is gone, so you move to the network. For a camera phone the same logic runs the other way round: the socket is already spent on power, so everything you want to do to that device, you do over the network — configure it, watch it, pull files off it, check on it.

It is worth noticing how much this constrains the design of any phone-as-camera setup. The device is, in practice, headless and cable-less from the moment you mount it. Anything that can only be done by plugging in is something you will not be doing again.

The hardware that changes the arithmetic

There is a category of adapter that splits one connector into a power input plus one or more data ports. Docks and hubs for laptops and tablets do this routinely, and some are sold specifically for phones.

Three honest caveats, and I am not going to pretend past them:

1. I cannot tell you it will work on your phone. Google's sentence above is the reason — support is hardware-dependent, regardless of platform level, and no vendor publishes a compatibility matrix for this.
2. I am not naming a model or a price. Anything I recommended today would be discontinued or re-specified within the year, and a confident recommendation from someone who has not tested your handset is worth nothing.
3. Two devices behaving differently is normal here, not a fault in either. A hub that charges a tablet and refuses to charge a phone is a common and boring outcome.

How to find out, in one sitting, without buying anything

You almost certainly have the hardware for this test already, or someone in the building does.

1. Take a baseline. With the phone charging normally and nothing else attached, note what the battery indicator does over a quiet half hour. That is your control.
2. Borrow before you buy. A hub from a laptop, a dock from a tablet, a wired adapter from a games console. You are testing behaviour, not buying equipment.
3. Attach it with the phone near full and watch the indicator. Does the charge climb, hold, or fall? That single observation answers the entire question. A phone that holds or climbs while hosting something is a phone that can do both jobs. A phone that falls is telling you the socket has one occupant and you already know who it is.
4. If you are testing a network adapter, plug it into a live network point and look through Settings for a connection type that was not there before. Then turn the radio off and see whether the phone is still reachable from another device in the house. Reachable with the radio off is the only result that counts.
5. Write the answer down with the rest of the setup notes. This is the sort of fact you will need again in a year and will not remember, and it is specific to that one handset.

If the answer is no, nothing is broken. You have found a hardware boundary that Google declined to document, on a device that was designed to be carried rather than installed.

What this costs the argument for using a phone

A purpose-built camera separates these jobs in hardware. It has a power lead, and the wired models either have a second lead for the network or carry both down one cable. That separation is quietly a large part of what the money buys, and it is fair to say so.

The phone gives you a very good sensor, an enclosure, a processor and a web server for nothing, and it gives you one socket. Almost every limitation in this catalogue has a workaround that costs only attention. This one has a shopping list and a compatibility question at the end of it, and it is worth knowing which of the two kinds of limitation you are looking at before you start buying adapters.

The app I build for this is Background Camera RemoteStream; the rest of the guides are at superfunicular.com. Neither of them can add a second socket, and nor can anyone else's.