Develop Reference

Android 11 AOSP AB STREAMING update https problem

I am trying to write my own AB STREAMING update based on https://android.googlesource.com/platform/bootable/recovery/+/master/updater_sample and after many days of developing and decomposing looks it good.
But I have big problem with using https protocol (which is required by default). When i try to call method applyUpdate(Context context, UpdateConfig config) from UpdateManager, I got error 9 (DOWNLOAD_TRANSFER_ERROR) immediately.
It's interesting, because all other metadata were downloaded without problems. It looks problem is only with downloading of payload.bin.
When I try to change protocol from https to http (by enabling in manifest of course and changing link in json file) no problem appeared.
So questions are:
Is it bug in android? Do you have the same problem (I found another question one year ago but without reaction). Is there any special request for https, webserver...
Yes, I can leave http protocol enable, but I am afraid of new steps from Google, they can forbid this option.
Thank you
D

I was facing a similar issue where the Streaming AB OTA update was failing with error 9 (DOWNLOAD_TRANSFER_ERROR) but on Android 10.
Here are the logs from my device
E/update_engine: [1003/030413.677875:ERROR:libcurl_http_fetcher.cc(436)] Unable to get http response code.
I/update_engine: [1003/030413.678370:INFO:libcurl_http_fetcher.cc(467)] Transfer resulted in an error (0), 46484 bytes downloaded
I/update_engine: [1003/030413.678435:INFO:libcurl_http_fetcher.cc(481)] No further proxies, indicating transfer complete
I/update_engine: [1003/030413.678483:INFO:multi_range_http_fetcher.cc(172)] Received transfer complete.
I/update_engine: [1003/030413.678528:INFO:multi_range_http_fetcher.cc(129)] TransferEnded w/ code 0
I/update_engine: [1003/030413.678572:INFO:multi_range_http_fetcher.cc(144)] Didn't get enough bytes. Ending w/ failure.
I/update_engine: [1003/030413.678675:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kDownloadTransferError
I/update_engine: [1003/030413.678723:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
I/update_engine: [1003/030413.678785:INFO:update_attempter_android.cc(454)] Processing Done.
I/update_engine: [1003/030413.678834:INFO:dynamic_partition_control_android.cc(151)] Destroying [] from device mapper
D/OTAManager: onStatusUpdate invoked, status=0, progress=0.00
D/OTAService: onProgressUpdate() called
D/OTAService: OTA Progress :0
I/OTAService: onEngineStatusUpdate - status=IDLE/0
D/OTAService: Sending Response to Client:- Msg:6 Data:0 Status:IDLE D/OTAManager: onPayloadApplicationComplete invoked, errorCode=9
D/OTAManager: setUpdaterState invoked newState=1
D/OTAService: onUpdaterStateChange state=ERROR/1
I/OTAService: onEnginePayloadApplicationComplete - errorCode=OS Update failed due to an error in fetching the payload/9 FAILURE
"libcurl_http_fetcher.cc: Unable to get HTTP response" => This is the culprit.
To know why this is happening I ran the following commands:
adb shell
curl -i https://myurl
To which the response was
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
I guess I need to update the SSL certificate on the server. However, your issue might not be exactly the same. But running the "curl" command from ADB shell might give you a clue.
Hope this helps.

Android: FacebookAuthorizationException appears sometimes

Since couple of weeks this exception appears sometimes on my App:
Non-fatal Exception: com.facebook.FacebookAuthorizationException: CONNECTION_FAILURE: TigonError(2): TigonLigerErrorDomain(2) AsyncSocketException: connect failed (immediately), type = Socket not open, errno = 101 (Network is unreachable)
at com.facebook.login.LoginManager.onActivityResult(LoginManager.java:218)
at com.facebook.login.LoginManager$1.onActivityResult(LoginManager.java:173)
at com.facebook.internal.CallbackManagerImpl.onActivityResult(CallbackManagerImpl.java:95)
at com.myapp.util.connect.FacebookConnect.onActivityResult(FacebookConnect.java:338)
Facebook SDK: 4.27.0
Android version's impacted: 4.4.2 and 7 (Crashlytics informations)
Have you got some ideas guys about this exception?
Thank you very much
UPDATE
I wrote a ticket on Facebook support, and after several messages, the last is:
Hi Anthony, thanks for the additional details. Looking at the data for your app,
there don't seem to be any failed API calls logged for your app. This indicates
that the login attempts failed before they reached our servers, and confirms
that this was indeed due to network errors.
I agree that it's not the ideal experience for users to have to retry their
login attempt, but in the case of network-related issues like this, this is the
best approach. I would recommend prompting the user to check their device
connectivity and initialize the login flow again.
From debugging this, it's unlikely that this is due to compatibility issues with
Retrofit, though I can't rule it out with certainty. It's more likely that the
affected users simply experienced a temporary drop in connectivity.
I'll mark this as closed since there doesn't seem to be a bug within the
Facebook SDK, but if you're able to get any information that would indicate
otherwise (for example, a way to consistently reproduce the error on a device
that has full internet connectivity), please let me know and I'll be glad to
help look into this again.

This exception means that user of your app is experiencing problems with his Internet connection. It is a problem that all the developers should care when making network calls, but it is especially important for mobile devices (the quality of mobile internet can be significantly low). Unfortunately netwok errors cannot be eliminated completely.
The common way of solving such a problem is making retries: either on the side of the app (retrying, showing user an error only after several network errors), either on the side of the user (suggesting user to try once more).

Error codes in Nearby Connections 2.0

I've been experimenting with the new Android Nearby Connections v2.0 API. Most of my devices can now talk to each other most of the time, but I also get a lot of error codes back when trying to connect. Checking status.getStatusCode() inside my program, I can see the following return codes:
STATUS_ALREADY_CONNECTED_TO_ENDPOINT (8003)
STATUS_BLUETOOTH_ERROR (8007)
STATUS_ENDPOINT_IO_ERROR (8012)
STATUS_ERROR (13)
I'm having a hard time making sense of these. The first error code seems self-explanatory, except that I see it in cases when I haven't hit the onConnectionResult callback with a "SUCCESS" return code on either side of the alleged connection. My current code is full of trace statements, and I'd see logging entries if those callbacks had been reached. So maybe the devices are connected at some lower level, but if so, the higher-level code doesn't always hear about it.
I'm guessing that STATUS_BLUETOOTH_ERROR indicates a Bluetooth error on the side that logs it, while STATUS_ENDPOINT_IO_ERROR indicates an error (probably involving Bluetooth) on the other end? Is it possible to get any more details?
The STATUS_ERROR (13) status that I see once in a while sounds like the sort of error code a programmer would use for those "WTF, we should never get here" moments, but without access to the source code, I can only guess.
Note that I see these errors between devices that talk to each other beautifully at other times, using the same code. Sometimes if the code retries enough times, it eventually gets a stable connection. Sometimes it connects and gets instantly disconnected from the other end. Sometimes I just get an endless stream of repeated error messages (STATUS_BLUETOOTH_ERROR and/or STATUS_ENDPOINT_IO_ERROR).
I'm using Nearby Connections with the connection strategy P2P_CLUSTER. These problems seem to happen most often when both sides do both advertising and discovery. However, I wrote two smaller programs that specialize in either advertising or discovery, and they sometimes get these errors too (but less often).
In the trace messages, I've also noticed lots of warning messages from Nearby Connections that look like this:
09-04 22:54:40.070 3866-3924/? W/NearbyConnections: Cannot deserialize BluetoothDeviceName: expecting min 16 raw bytes, got 6
I'm guessing that this is because Nearby Connections uses its own short tokens (like ZGbx) instead of the device Bluetooth name? I'm not at all sure about that, though. And anyway, if these are Nearby Connections' own special tokens, then why would it be issuing warning messages about it?

[Disclaimer: I work on Nearby Connections] I can try and help out.
STATUS_ALREADY_CONNECTED_TO_ENDPOINT: This occurs if you call 'requestConnection' while you have any pending (onConnectionInitiated) or established (onConnectionResult) connections to the given endpoint. Move your log statements earlier, to onConnectionInitiated, and you should see why we throw this error.
STATUS_BLUETOOTH_ERROR: Something went wrong with Bluetooth. The phone is probably in a bad state. This (hopefully) shouldn't happen too often. But if you really want a fix, stop advertising & discovery before reattempting requestConnection. Nearby Connections will toggle Bluetooth when it detects this error, but only if nothing else is going on.
STATUS_ENDPOINT_IO_ERROR: We lost connection to the other device. This can happen for a variety of reasons (they could have walked too far away, Bluetooth was flaky, the device stopped responding, etc). If you're discovering while you have connections, avoid that. Discovery can be hard on the phone and reduces bandwidth at best, causes dropped connections at worst.
STATUS_ERROR: Something went wrong that didn't fit well in the other error codes. It's a catch-all. This is most-often returned in onConnectionResult(FAILED), to notify you that something went wrong in between onConnectionInitiated and waiting for both sides to accept the connection.
We've also lowered the log severity of "Cannot deserialize BluetoothDeviceName" in an upcoming release, since it's not really a warning. It's like you said; expected behavior when we see non-Nearby Connections devices while discovering.
If you continue to see problems, let us know what devices you're using and we'll be sure to add them to our test suite.

I just want to add that it may be necessary to have a short client name string when calling the API.
E.g., Nearby.Connections.requestConnection(googleApiClient, shortNameHere,....)
I had been generating my own client name with UUID.randomUUID().toString() and that seemed to cause the STATUS_BLUETOOTH_ERROR.
All I did was change the code sample to use a UUID name and to use P2P_CLUSTER and I got that error.
This was the solution for me regarding the STATUS_BLUETOOTH_ERROR.

Cordova 3.5.0 return 0 sometimes ,for navigator.connection.type

i am trying to develop a cordova(3.5.0) project in android platform and in that i have to check network connection availability before each API call. for that i am using 'navigator.connection.type',and some times it return 0. why this is happening? plz help me for solving this trouble

Without some more details I can only guess.. There are some conditions which may cause this.
navigator.connection.type = 0 -> connection type unknown.
So you may have a connection, you may not it simply hasn't been determined yet, or because of privileges the device isn't saying.
Are you calling this check too early? ie before deviceready
In our app we do not check the connection each time but we handle it this way:
by making the API request anyway, knowing that its possible to fail, we set a timeout and error handling. If it fails by error or timeout we check connection type and then ping the server with a simple "hello" "acknowledge" request. Its a super small request that we figure will work or if it timeouts again the connection must be so poor it might as well be disconnected.
This is because there are really two types of connection you need to check. Many miss this!
And also because its navigator totally lies some times... :/
Just because wifi is on and connected and navigator tells you this, it doesn't mean you will have a connection to the outside world. You need to check the network hardware (which is all navigator will tell you) but you must also check network connectivity, if this is something you are sensitive about.

Android sipdemo timeout when making calls

Having a problem with the android sipdemo timing out when making calls. The native sip client on the phone has no issues calling, works perfect. Its When i initiate the call within the sipdemo i get a timeout in the logcat. timeout is set to standard of 30 seconds.. a local asterisk box is what its connecting to. Registers fine.

I'm having the same problem.
I traced packages in wireshark and here's what I found:
I register to SIP server in SipDemo
I register to SIP server on Desktop (using Ekiga)
I place a call in SipDemo to Ekiga.
INVITE message gets sent to Ekiga
Trying is sent from Ekiga to the server
Ringing is sent from Ekiga to SipDemo
I answer the call on Ekiga client
OK (with session description) is sent from Ekiga to SipDemo. This happens 11 times before Ekiga just gives up
BYE is sent from Ekiga client to SipDemo
Please note that OK is being sent 11 times before Ekiga just gives up and ends the call. This is why the call lasts just 30 seconds.
If you take a look at the RFC here:
http://www.ietf.org/rfc/rfc3261.txt section 13.3.1.4
you can see that the reason Ekiga is giving up on SipDemo client is because it never gets ACK back from SipDemo.
I believe this is android bug, but I can't imagine they could have missed something this basic in their SIP implementation.
In the next few days, I'll try to dig up some answers in android source code...
I'll try see what happens when establishing calls between 2 SipDemo applications. If it works, that means android just ignores ACK all together.
EDIT:
I just tried a call between 2 SipDemo clients. It sends OK 5 times and gives up on the OK, but does not end the call. Interesting behavior :)
EDIT2:
I dug up androids SIP implementation, and I found that ACK should get sent... Even logcat logs this, but I still see nothing in Wireshark. I thought maybe it gets blocked or something, so I ran Shark (like Wireshark for android) on the device, pulled the dump to my laptop, opened it up in Wireshark, and I don't see ACK anywhere. I even looked trough all packets... No filters, just in case I might be filtering it out. Anyways... Here's what I found in android code:
http://hi-android.info/src/com/android/server/sip/SipSessionGroup.java.html
class: SipSessionImpl
method: private boolean outgoingCall(EventObject evt)
in case Response.OK:
you can see this call:
mSipHelper.sendInviteAck(event, mDialog);
In SipHelper, method sendInviteAck, you can see:
if (DEBUG) Log.d(TAG, "send ACK: " + ack);
dialog.sendAck(ack);
Dialog is nist javax.sip, so I don't think there's a need to go further...
I see this message "send ACK" in my logcat when running the application
EDIT3:
I noticed that this issue occurs only with some SIP servers. I now tried opensips, and it works fine. I guess the problem I was having had to do with the server responding to androids keep-alive OPTIONS messages with 404 Not Found. Then, android tried to not use the server as soon as possible. Because of that, as soon as android got the address of its peer client, it tried to send a direct message, and failed

Hard to tell just like that. Try capturing the packages with wireshark, filter for the SIP protocol and have a look at what is sent over the network. Also try it with the native client and compare it to the sipdemo.
Another starting point is the log of your asterisk instance (systemlog)
If you can't figure it out yourself, post the results here.