We created an external iOS notification light that uses the device’s audio for power.
When you get a phone call on iPhone and the light is plugged in, you still get the ringtone but when you pick up, the audio is rerouted to the headphones (the iPhone thinks our light/device is a headphones set) and the user has to extract myLED for at least 2mm to get the audio from the front receiver of the phone.
We have been exploring alternative solutions to this challange - recently we made a prototype with a particular jack shape so that it could be rotated by the user when getting a call to "reroute" the audio to the iPhone speaker/mic.
Although it may sound a clever option, this hardware solution is far from being neat - this leads to having positions where the myLED does not work/ it is not reliable, plus other complications.
I know of the existence of kAudioSessionOverrideAudioRoute_Speaker however I suspect that this will only direct the app audio to the rear speaker (the “loud” one) and not to the front receiver (because the “receiver” for the iphone is the headphones set if they are detected).
What would you suggest?
Super appreciated!
I think you're in a tough spot:
It's highly unlikely Apple will ever release the option to override audio routing for phone calls. As a key functionality of the phone, they tend to keep the call aspect under lock and key.
The headphone jack (probably - this is how most of them do it) uses the impedance between ground and one or both speakers or the remote control to determine if the plug is in. Other than breaking the circuit, there is no good way to simulate this.
The only options I think you have are these:
Require the user to remove the device when a call comes in.
Provide a microcontroller on the jack to drive a transistor; this transistor can electronically break the circuit to provide the same sort of impedance signature as an unplugged jack.
How, when, and if you can provide the information to the jack that a phone call is in progress is beyond my knowledge: is there an API for "incoming but not yet answered call" you can hook to? Will you have to do a watchdog thing to ensure communication with your app? Would it be possible for you to use the dock connector instead? I think these are really your options. Not a complete answer, but those are my thoughts.
Related
So with iOS 8, we can now record the screen of iOS devices. I've searched extensively and cannot find a way to detect, let alone prevent, this recording. The app I'm working on deals with some potentially sensitive information and images and would like to prevent this if at all possible.
Thank you in advance for your responses and insights!
Anthony
Apparently, there is some way to detect whether a display or QuickTime streaming is connected, because the Netflix app will show an error when that is the case (which also means you can't just use an iOS device and stream to your computer to watch it in big). The app works perfectly if QuickTime streaming is off with the cable is plugged in.
Maybe it just detects whether an external display is connected, and screen recording behaves like that, so basically you might have some success with these APIs and notifications.
Also, you could use an encrypted HTTP Live Stream according to Apple which would be blacked out in the stream / the recording.
I have an app that displays videos, and it's very important to us that we intercept all pause events, and prevent users from seeking in videos.
Doing it on device is pretty simple, we just don't expose any 'regular' controls to user, and in -remoteControlReceivedWithEvent:, we wrap all events that we're actually interested in.
But we're struggling with supporting Apple TV. It's our understanding that it should forward all events sent from Apple Remote to our app, as per [0]:
When AirPlay is in use, your media might be playing in another room from your host device. The AirPlay output device might have its own controls or respond to an Apple remote control. For the best user experience, your app should listen for and respond to remote events, such as play, pause, and fast-forward requests. Enabling remote events also allows your app to respond to the controls on headphones or earbuds that are plugged into the host device.
However, as far as I can see from my debugging and pulled hair, it doesn't apply to cases where you let AVPlayer handle displaying your video. We actually don't do anything at all to make videos play on TV, since AVPlayer's allowsExternalPlayback property is YES by default.
If I'm understanding docs correctly, while using that mode with Apple TV, only URL/data from device is sent to Apple TV, and aTV does the decoding and rendering part on it's own, as per [1]:
External playback mode is when video data is sent to an external device such as Apple TV via AirPlay and the mini-connector-based HDMI/VGA adapters for full screen playback at its original fidelity. AirPlay Video playback is also considered as an "external playback" mode.
which could potentially explain why I don't receive any events on device (e.g. someone at Apple thought that since aTV does the heavy lifting and actually decoding and rendering, apps on device shouldn't receive those events).
So, my question is basically this - is there any obvious tree I'm missing from the forest, or do I have no retreat other than either:
ugly hacks using KVO on playback position and playback rate, and punishing users for 'cheating'
reimplementing whole video rendering on my own, treating TV screen as second display
Any pointers will be greatly appreciated.
[0] https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/AirPlayGuide/EnrichYourAppforAirPlay/EnrichYourAppforAirPlay.html
[1] https://developer.apple.com/library/ios/documentation/AVFoundation/Reference/AVPlayer_Class/Chapters/Reference.html#//apple_ref/occ/cl/AVPlayer
Can information that gets transferred through the headphone jack be stolen by a backgrounded app?
Square makes a card reader that plugs into the headphone jack of the iPhone and transfers your credit card info to your phone.
There are many devices that transfer data through the headphone jack.
Since you can run background processes now on iOS, can that information that is being transferred be intercepted or monitored by an app running in the background?
Could a random app potentially be listening and looking for credit card numbers and steal the information?
If yes, then is there a way to cancel all other app's listening connection to the headphone jack while I transfer my own data from a device?
I have looked at the AurioTouch example of how to transfer data but all I need to know right now is if my data is in jeopardy of being stolen and how I can prevent that.
See the last paragraph of "Playing and Recording Background Audio" here.
To sum it up, you can stop your app from playing or recording audio if another app wants to play/record audio. Look into AVAudioSession.
You should be equally worried about the possibility of audio being intercepted on the outside of the device as audio. Such man-in-the-middle attacks have been reported against chip-and-pin terminals, and usually involve corrupt employees of the retailer using the device or social engineering.
The only solution is to encrypt the data. This makes the question of interception on the device irrelevant.
I am trying to set one pin of the old iPhone 30-Pin Connect from low to high so the best would be from 0V to 3,3V. Is that possible with a simple PodBreakout board like this?
https://www.sparkfun.com/products/8295
If not can you send a constant voltage out of the iPhones audio jack (This could be a good method too, cause now apple used its 9-Pin Lightning Connector).
I already searched the web, some say you have to jailbreak your iDevice, some say you need an authentication Chip, and some say it works flawlessly without an authentication chip, but I cant find any help online.
Thanks
You can't "send a constant voltage" out of the audio jack. There is a series capacitor there that filters out DC and very low frequency signal components.
To get proper help on this you can apply for the MFi program. I think it's free for educational purposes. It's under 100$ for sure. There is an NDA involved.
If you want to avoid the MFi you can always use BLE to communicate with periphery.
Or try to implement software FSK (or DTMF) modem on one side and a hardware one on the other side (using the audio lines).
Since it seems you simply want so see a binary (on/off) signal - you could generate a fixed pitch tone in the app (2kHz for example) and use a narrow-band filter on the hardware side (audio-jack connection).
Or maybe (to make sure your app is present on the other side a 2kHz tone would mean 0 and a 4kHz tone could stand for 1.
The authentication chip (and an MFi license)) you are talking about is needed when you try to communicate with the iOs device:
via BT (excluding BLE)
via USB (30 pin connector or lighting connector)
via UART (30 pin connector or lighting connector)
I would like to play a sound file during a phone call so that the person at the other end of the line can hear it clearly.
I know it is possible to play sounds on the line but i can't figure out how to cut the microphone at the same time so the person at the other side of the line don't hear ambient noises.
Does someone knows how to do that? Or have any cue where I could look for information?
I very much doubt it is possible.
A telephone is an emergency communication device. The inability to make, receive or even clearly hear a phone call could literally kill someone. Consequently, the iPhone API strongly protects the integrity of the phone before all other functions.
Even if you did figure out a way, I doubt Apple would let it through. (Think of the liability issues for them and you!) The iPhone isn't a very small laptop, its a phone with a computer attached and the phone comes first.
You should always consider that when starting a design.