When the transferring session was stopped, mBodySegmentLength wouldn't reset
to 0, and that would impact the next transferring if the first packet of the
next transferring doesn't contain header Body or EndOfBody, which would invoke
ExtractPacketHeaders() and refresh mBodySegmentLength in the function.
The original implementation would be stuck on OPP server side after dealing with
ABORT packet. This is because we do something only should be done when receiving
DISCONNECT packet.
There are still a handful that either are used with other runtimes, or that
happen very early/late in cx the lifetime of various things where it doesn't
necessarily make sense to have a cx on the stack. This should definitely ensure
that we're not doing double-duty with the nsCxPusher change, though.
Bluetooth file transfers store the file in 'downloads/bluetooth'. This
patch changes the location to 'Download/Bluetooth' for consistency with
other sub-systems.
Things we have done in this patch:
1. Make BluetoothHfpManager/BluetoothOppManager implement BluetoothProfileManagerBase
2. Add function BluetoothService::GetServiceChannel()
3. Once GetServiceChannel() is done, callback Bluetooth*Manager::OnGetServiceChannel() will be invoked
4. Remove unused function BluetoothService::GetSocketViaService()
BluetoothProfileManagerBase is a base class of Bluetooth profile managers.
It will be a generic interface declaring basic functions that all profile
managers should implement, such as Connect(), Disconnect() and IsConnected().
Currently there is only one callback function OnGetServiceChannel(), which
will be called after calling BluetoothService::GetServiceChannel().
According to HFP spec, when we receive AT command 'AT+BLDN', we shall respond
with:
1. 'OK' if the call history is not empty. An outgoing call would be made
2. 'ERROR' if the call history is empty. No call would be made.
However, with current implementation, we are unable to know whether the call
history is empty or not in Gecko. Therefore I introduce a solution, using a task
and a flag to decide if a call is made after AT+BLDN is received, which may not
be perfect but reliable, easy to understand and easy to implement.
When we receive multiple files in a row, we need to notify observers of
file-changing whenever a file is completely received. Currently we only
send one notification at the end of the entire session.
