If your code is blocked in a system call when a signal needs to be delivered, the kernel needs to interrupt that system call. For something like a read(2) call where some data has already been read, the call can just return with what data it has. (This is one reason why read(2) sometimes returns less data than you asked for, even though more data is available. It also explains why such behavior is relatively rare, and a cause of bugs.)
But what if read(2) hasn‘t read any data yet? Or what if you’ve made some other system call, for which there is no equivalent “partial” success, such as poll(2)? In poll(2)‘s case, there’s either something to report (in which case the system call would already have returned), or there isn't.
The kernel's solution to this problem is to return failure (-1) and set errno to EINTR: “interrupted system call”.
Technically, yes. In practice on Android, no. Technically if a signal‘s disposition is set to ignore, the kernel doesn’t even have to deliver the signal, so your code can just stay blocked in the system call it was already making. In practice, though, you can‘t guarantee that all signals are either ignored or will kill your process... Unless you’re a small single-threaded C program that doesn‘t use any libraries, you can’t realistically make this guarantee. If any code has installed a signal handler, you need to cope with EINTR. And if you‘re an Android app, the zygote has already installed a whole host of signal handlers before your code even starts to run. (And, no, you can’t ignore them instead, because some of them are critical to how ART works. For example: Java NullPointerExceptions are optimized by trapping SIGSEGV signals so that the code generated by the JIT doesn't have to insert explicit null pointer checks.)
You won‘t see this in Java because the decision was taken to hide this issue from Java programmers. Basically, all the libraries like java.io.* and java.net.* hide this from you. (The same should be true of android.* too, so it’s worth filing bugs if you find any exceptions that aren't documented!)
For most people, things would be easier if libc hid this implementation detail. But there are legitimate use cases, and automatically retrying would hide those. For example, you might want to use signals and EINTR to interrupt another thread (in fact, that's how interruption of threads doing I/O works in Java behind the scenes!). As usual, C/C++ choose the more powerful but more error-prone option.
In most cases, the fix is simple: wrap the system call with the TEMP_FAILURE_RETRY macro. This is basically a while loop that retries the system call as long as the result is -1 and errno is EINTR.
So, for example:
n = read(fd, buf, buf_size); // BAD! n = TEMP_FAILURE_RETRY(read(fd, buf, buf_size)); // GOOD!
TL;DR: never wrap close(2) calls with TEMP_FAILURE_RETRY.
The case of close(2) is complicated. POSIX explicitly says that close(2) shouldn‘t close the file descriptor if it returns EINTR, but that’s not true on Linux (and thus on Android). See Returning EINTR from close() for more discussion.
Given that most Android code (and especially “all apps”) are multithreaded, retrying close(2) is especially dangerous because the file descriptor might already have been reused by another thread, so the “retry” succeeds, but actually closes a different file descriptor belonging to a different thread.
System calls with timeouts are the other interesting case where “just wrap everything with TEMP_FAILURE_RETRY()” doesn‘t work. Because some amount of time will have elapsed, you’ll want to recalculate the timeout. Otherwise you can end up with your 1 minute timeout being indefinite if you‘re receiving signals at least once per minute, say. In this case you’ll want to do something like adding an explicit loop around your system call, calculating the timeout inside the loop, and using continue each time the system call fails with EINTR.