How to read a digital input (an open/closed switch) from a smartphone without a digitizing board

Usually electret/condenser microphones require power to operate. These microphones are also called as capacitor microphones. There is a capacitor whose one plate will move as per the sound waves. This will cause a change in the capacitance which is equivalent to the sound waves.

In order for these microphones to work, power is required. Capacitors has rtto be charged to see the capacitance varying. These microphones are powered from the same audio line of the amplifier. If there is no power reaching the microphone, then it can't operate. Hence it draws small amount of current.

It is normal that these microphone consumes power. For any electric circuit to work, current is required. Each device you connect to your phone will consume power. Since the current consumed is 0.17mA, you won't notice a big difference in the battery life.

From diagram 3, I could think of two possibilities:

1. The microphone interface is polling for an existence of a mic periodically and turning the line off when not found. Probably not correct.

2. The mic input is doubled as another digital interface. Some phones have a way to detect whether the plugged in ear phones are manufacturer's original models or not, for example. If such a earphone pair is detected, the internal audio equalization may be tweaked to produce best possible fidelity.

The pulse shows narrow, I could not sit and figure out it's width, but it does look like a start bit for me. Assuming it is a start bit, it is probably followed by, say some bits and a stop bit - all are zeroes (like a UART). Beyond that, the controller probably is expecting a response.

The first diagram probably is the mic decoupling capacitor acting as weird RC filter with oscilloscope input impedance. Open drain outputs usually require a remote termination. That's another way to detect if remote is connected, somewhat like USB.

Which is the phone on the other end? I might not have access to the same model and I definitely don't have a similar cable handy to figure exactly out what is happening.

It might be interesting, though, to try sending an UART response on the line, taking the high pulse width as bit time: wait for ten or 11 bits and send high start bit and probably try some combinations. Even if we get a response, it might take a while to figure out the protocols etc. I would advise extreme caution, though - if it is a dangerous interface like a firmware backdoor, a trial sequence could potentially erase the flash.