This CL fixes serveral issues with the createConnection code:
- it uses failureCode/failureMessage which were never set.
Renamed to disconnectCode and disconnectMessage and set
those fields in Connection.setDisconnected
- Connection.CANCELED_CONNECTION was static and it caused
lots of log spew which was confusing. Changed to create
a new connection every time, same as failure
- moved sNullConnection from Connection to ConnectionService
- made FailureSignalingConnection private and removed type
checks for it. Using disconnect code is better, this is
already what ConnectionServiceWrapper does
Note, the current code still expects connections to be cancelled
or failed in synchronously. This bug is being tracked separately.
Bug: 17156304
Change-Id: I0b13a78b738c4bf37a69de9fd5dcd17be0c45c14
Refactor ConnectionService API so it has only one "completed"
callback, and connection state and failure codes indicates what
happened. Previous design where we had separate callbacks for failure,
cancellation and success was error prone because it was easy to forget
to implement one of them.
Bug: 16993846
Bug: 17070939
Change-Id: I84bf5d041cf78193ccf80db201b08db3b7014830
Telecomm was not sending the initial state for new connections forcing
the connection services to postpone when they set data on the connection
which resulted in hacky code. This CL makes use of a
ParcelableConnection to send the intial connection data.
Change-Id: If571414aba19fa1bb282e30632431962b8366cf4
