Make b2g-dialer-daemon a submodule, and have the utilities it builds be built into the B2G image.

Create a radio class that can talk to file sockets, so we can communicate with the radio when on the phone

The less android libraries we can link in, the better. See if we can use the nsBinaryOutputStream class to replicate what we need from libbinder.

http://dxr.mozilla.org/mozilla/mozilla-central/xpcom/io/nsBinaryStream.h.html

It'd be nice to turn the event documentation in ril.h into a wiki page or something so we can match the events to Gecko hooks. Need to figure out where to centralise the information (wiki on this project? B2G mozilla wiki?) then actually do it.

All radios will need to maintain a buffer queue of what's going in/out of the sockets. Build this into the base class, so that the subclasses simply specialize communication behavior.

If we're going to use android libs, we need to figure out exactly how we're going to build against libbinder (for Parcel), libcutils (for some dependencies of libbinder), libaudio (for audio stuff), etc... These are all located in the B2G tree at the moment.

Once we know what the raw I/O looks like, correlate it with the actual java source that's creating it. That way we can check for any error cases we need to handle that we might not see in the raw dumps.

We can dial, but we can't hang up. We should probably be able to hang up.

Once we have a simple I/O loop so we don't drop events, we need to figure out how we'll route events into gecko. @benturner is in charge of the gecko side of this, so we'll need to talk to him about how callbacks (or whatever method is decided to use) should look.

Using a regular old android phone, run

• strace -p (rild pid) -f
• logcat -b radio

And add the output to documentation. This'll give us a way to hand trace the steps needed in dialing. This is only to the point of getting the phone ringing, not interested in pickup/hangup yet.

The CMake project here is still just for the edification of @kmachulis-mozilla, but since other people may be using it, it'd probably be best to remove the hardcoded paths. Just create a single B2G location configuration variable and use that for the INCLUDE/LINK setups.

Microphones are helpful when you want to talk to someone. Figure out how to turn it on/off. Doesn't need to directly correlate to events, just need information

Create something similar to rild for setting the speaker/mic via libmedia, so we can change settings via outside means. Having this means we can test the full phone flow from the desktop (by exposing more sockets in b2g-dialer-forward or a similar utility)

Create a radio class in mozilla-central that can talk to a network socket, so we can do desktop m-c dev for the telephony DOM.

Speakers are pretty important to phones. Figure out what is needed to turn speaker on/off during calls. Doesn't need to directly correlate to events, just need information

It's not specific to b2g or the dialer per se, just a proxy for the ril socket. IMHO this name is actively confusing.

I suspect this might evolve to contain ril-specific state, not remain a dumb socket proxy, so something like rilproxy might be descriptive going forward. If all the state we might need to reload after a gecko crash, e.g., is queryable from rild, then this can remain a dumb proxy and we might want to use a standard tool.

Figure out what the basic requirements are for getting data flowing over the cell network

In order to be able to test how the radio classes work, create a native xpcshell test that brings up an instance of a radio object.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

When connecting to the socket, the phone sends some unsolicited information (phone type, gsm info, etc...). We should figure out exactly what is required of the protocol to go from socket connection to a stable, idle phone state.

Our code bases are currently diverged. I know @jaoo mentioned creating a fork of this repo and integrating his code at andreasgal/B2G#27. Just creating an issue for that here.

Create a protocol diagram (similar to http://www.kandroid.org/online-pdk/guide/images/telephony_solicted_example.gif) for javascript calls down to the RIL communication layer, for the flow of phone dialing

Create a simple poll() based loop to make sure we read/write all the events, even if we don't do anything with them. rild gets angry if you drop events.

Once we can get these events, forward them to a network socket so we can connect via adb forward. This will allow us to develop phone RIL on desktop m-c, so we don't have to forward to the device every time we make a change to the RIL code.