Seeing External exception 0 error using TRESTRequest on some Samsung phones

[Chris Pim 32]

We've been having a strange issue using the TRESTRequest component with some of our users.

When we call the request.execute on those devices, it always raises an exception with the message of "External Exception 0". Weirdly it only seems to happen on Samsung devices, particularly newer models such as the S22 Ultra (but not exclusively that device).

 

It happens for every API call we make, but only affects our app. The user reports that all their other apps can talk to the internet fine, so not sure what this could be.

 

We have a number of newer Samsung test devices but can't reproduce this issue. The error seems to be coming from the OS rather than Delphi, but I can't see any reason for it.

We've been exploring device config-specific factors such as firewall apps, disabling data access to the app etc but there doesn't seem to be anything special. Most affected users keep their devices as factory default for these settings.

I've extract a logcat from those devices (I don't have physical access to the device though), and it doesn't show any errors, warnings or messages related to network access, security or things I would expect if the OS was the cause.

 

We're running out of ideas, and the users are becoming frustrated as they can't use the cloud features of our app.

 

I'd really appreciate any thoughts, suggestions or even just troubleshooting theories that could help to figure this out.

 

Thanks!

[Martifan 5]

This indeed sounds like a challenging issue. A device-specific and vendor-specific problem can be tough to debug. Here are some steps you can take to troubleshoot the issue:

Android Version: Check the Android version on the affected devices. It might be possible that there is some issue with a particular version of Android on these Samsung devices. Comparing Android versions between devices showing the error and those not showing the error might provide some clues.

App Permissions: Make sure that the app has all necessary permissions to access the internet and any other permissions that might be needed for your app to function properly. Users might have accidentally denied some permissions.

HTTP vs HTTPS: Check if the issue arises with both HTTP and HTTPS requests. Newer versions of Android have increased restrictions on plain text (non-SSL) network traffic.

SSL / TLS Protocol Issues: The Samsung devices may have different SSL/TLS protocol settings. They may not support the protocol that your server uses, or there may be a bug in how the device firmware handles a particular protocol. If your server supports it, you could try switching to a different SSL/TLS protocol version to see if it resolves the issue.

Network Libraries: TRESTRequest uses the platform's network libraries, which in turn use the device's firmware and potentially hardware-specific features. There might be an issue with these libraries on the affected Samsung devices. Try using an alternative HTTP library that doesn't rely on the platform's libraries (such as Indy, Synapse, etc.) to see if the issue persists.

Delphi Version: You may want to try compiling your app with the latest version of Delphi. Embarcadero regularly updates their platforms to support the latest changes in each OS, so there may be a fix available if the problem is due to a Delphi RTL or FireMonkey issue.

Server Side Issue: Investigate whether there's something specific about the requests coming from these Samsung devices that's causing your server to respond differently.

Debugging: Since you have logcat output, even if it's not showing any errors, you can still use it for detailed debugging. Add extensive logging to your application, particularly around the network requests, and then analyze the logcat output when the problem occurs.

User Community: Reach out to your user community. Ask if users experiencing the issue can provide any additional details, or if they'd be willing to help you test potential solutions.

Remember, isolating the problem is half the battle in cases like this. As you gather more information and rule out potential causes, you should be able to narrow down the possibilities and get closer to a solution. Good luck!

Edited August 3, 2023 by Martifan

[Chris Pim 32]

Thanks Martifan, those are very helpful.

I’m in the middle of working through these so I hope to figure it out soon.

[Rollo62 502]

An External exception is mostly the worst case, since this usually happens before you have any control over the app.

Very likely, this is caused by any permission or forbidden access problems.

 

I've learned the hard way, that it makes much sense to massively modularize the app and separate and encapsulate all specific features, to simplify separate feature testing on different devices.

Monolithic apps are so Windows - 1990

This philosophy doesn't work any more on mobile.

 

With ifdef defines, I can add/remove/compose certain features fast and easy, for step-by-step testing purposes, without touching the whole app.

That way, I can produce test-apps for specific customers, which are able to reproduce and test errors.

I use also massive logging, to follow the patch in the app, which also can be used in released apps.

[Chris Pim 32]

The app isn't a monolithic app (it's a large app but written to be modular) so that's not a problem we face. We always write apps properly - glad to head you do too Rollo 😄 

It's just the sporadic nature of the exceptions on specific devices we can't figure out. We've had to order a few more Samsung test devices to see if we can reproduce it, as the users are in a different country so no way we could get access to their devices. They respond for a while to help but don't tend to like us sending test apps and debug versions, as we're a relative unknown to them so don't fully trust we won't steal their data or hack their devices I suspect.

 

We'll figure this out I'm sure, but appreciate everyone's help and suggestions. I'll report back once we had a solution just in case anyone else has something similar in future.