Blog index–Rollingš„blog–Permalink
In one of my previous blog posts I mentioned writing an app for the purpose of 'forwarding' text and phone calls.
There is such a thing as call forwarding where phone calls to a number gets redirected/forwarded to another number. This is not what I mean.
What I meant was mirroring: a call to one device (with an actual number) will be a call on all associated devices. A call from any associated devices will call from the one device that actually has a phone number. The text and phone state of the primary device (the one with the number) will be mirrored on to the other devices.
I will document my current thoughts on this app, maybe someone else can go far with it (and hopefully release the project on F-Droid). I won't touch it for a while since I am dealing with other another project.
I am writing this because I haven't found any apps that do this. If it exists (and is free software), please let me know so I don't have actually have to learn Java.
Each device needs to be able to contact the server in order to even function. In an office or a home setting this is probably not an issue since WiFi will most likely be available. When out and about, connectivity can be an issue, even when using hotspot as the range of hotspot likely is under 20 yards and is easily thwarted by cars and nature and bricks, unless some contraption is used, perhaps a yagi antenna, or some other antenna, which requires preparation.
It is not a guarantee that mobile devices will be able to even physically connect to the antenna to broadcast hotspot or to 'receive internet' somehow, except perhaps with a usb-c to female usb port which the antenna connects to and even then, perhaps Android won't know what to do the antenna. To be honest, I don't foresee many cases where the perfect situation will occur. I do know that a lot of places offer 'free' (as in beer) WiFi.
But in the event connectivity can be found, what about latency and all these other restraints? A server 'far away' relatively speaking, could have to spend a REALLY long time passing voice data along (imagine constantly interrupting each other because the delay is like 2 seconds).
What about using Bluetooth?
The range of Bluetooth isn't long enough and from what I've read, generally what uses Bluetooth would interfere with whatever uses hotspot or 'xG' or WiFi. Also, in Bluetooth terminology there is 'Receiver' and 'Transmitter' and Android apparently doesn't like to be the receiver.
The 'owner' of the device (not the person who rents the device and has to ask permission to use it and give up certain rights or give Google/some-evil-company certain rights) may decide that this 'mirroring' thing is bad and somehow violates some random vague terms of their contract. They may put restrictions on such app capabilities, so it is possible that this project is already dead in the water. However, given that XMPP apps exist, I find this to be unlikely. The main thing, that I imagine that they might take offense to is another device commanding the device with 'cellular' capabilities to do things like calling and texting.
It is possible, for whatever reason, that Android without being rooted will not allow audio from a 'phone call' to go to another location.
Another possible problem, directing audio from another source (the other phone's microphone being sent via 'internet') so that the other party can hear what is being said.
Server: The device/hardware that relays messages and statuses to other devices.
Client: All connected devices that receive from and transmit to the server.
Client 'Data': The connected device that actually has a phone number and can send calls and SMS.
Client 'No Data': The connected device that does not have a working phone number and cannot send calls and SMS by itself.
S2C: Server to Client.
C2S: Client to Server.
A server simply mean the software that will relay messages and statues to other devices. It is not capable of client stuff. However, there should not really be anything stopping one from installing server and client software on the same device; thus making the device act both as a server and a client.
One will carry a 'non-data' device around in their pocket and leave a 'data' device behind. Both devices will somehow connect to the server.
A 'Data' Client will connect to the server through mobile data (assuming it already isn't the server) and the 'No Data' client would connect via Hotspot/WiFi and also connect to the server (assuming it isn't already the server).
The 'easiest' server configuration that I can think of is similar to how XMPP works; plainly a standalone server software and clients connect to the server. Outside of this, I have no clue how the server should operate.
I had ideas about how a phone could be a client and a server but quickly had issues in resolving things that would for certain show up.
Easiest way, without any real knowledge of what is required, seems like it would be to fork an already created SMS or Calling app and add 'mirroring' functionality to it. It would be best if there were two apps, one solely for SMS and one solely for calling, but I suppose I see nothing wrong with combining the two. The Apps should have 'server' option somewhere where they can specify where the server is, and what kind of client they are, 'Data' or 'No Data'. (It would be possible to write a desktop client too, which would allow one to send texts and call from desktop.)
I have no thoughts on what protocol they should or should not use, at the moment, besides some vague notion that VoIP could work for calling.
I do not have any thoughts on what data storage method text messages should be in or how they should be transmitted between clients.
Main contention point is for phone calls: Client 'Data' will need to both relay what the other party is saying, decode and transmit what Client 'No Data' says to the other party. Vice versa for Client 'No Data'. If there are more than one Client 'No Data' then I don't have a clue what should occur besides Client 'Data' should 'lock' speaking access to one Client. (Of course, Client 'Data' can speak to itself)
Call Mirroring seems like it would be the easiest to implement since it is just audio and you don't need to save it or anything. The Server will need to send the data to clients that need it.
There needs to be a case for the following:
If someone manages to associate their device with the server, they can do 'bad stuff.' Therefore, by default, the server needs to have reasonably good security policies for authorizing devices.
test on 2022-09-20,06:55:32 said:asdf
Due to abuse (the comments you see now are not abuse), commenting will be disabled for sometime. Send an email or something.