[Galaxy Note 3 Android Development] ronjwright:
I think I finally fixed the file leak bug that has been plaguing my phone in low signal areas. I have pinpointed the bug to com.android.internal.telephony.hlteRIL in android_device_samsung_hlte-common. Here is a patch with the fix:

diff -purN android_device_samsung_hlte-common/ril/telephony/java/com/android/internal/telephony/hlteRIL.java android_device_samsung_hlte-common_fixed/ril/telephony/java/com/android/internal/telephony/hlteRIL.java
--- android_device_samsung_hlte-common/ril/telephony/java/com/android/internal/telephony/hlteRIL.java	2015-03-06 12:32:07.383431946 -0600
+++ android_device_samsung_hlte-common_fixed/ril/telephony/java/com/android/internal/telephony/hlteRIL.java	2015-03-06 23:25:47.266219903 -0600
@@ -262,7 +262,8 @@ public class hlteRIL extends RIL impleme
Rlog.d(RILJ_LOG_TAG, "Executing AM: " + amString);

try {
- Runtime.getRuntime().exec("am " + amString);
+ Process p = Runtime.getRuntime().exec("am " + amString);
+ p.destroy();
} catch (IOException e) {
e.printStackTrace();
Rlog.e(RILJ_LOG_TAG, "am " + amString + " could not be executed.");

Notice that in the original code, the am command is run without the process instance being destroyed. This is what is causing file handles for the standard input, standard output, and standard error to leak. When the process instance is properly destroyed after finishing the execution, the issue of leaking file handles is fixed. To check whether my fix works, I did the following. First, I implemented the equivalent fix in the corresponding telephony-common.jar file using apktool (because, for me, this is the fastest way to try out fixes). Then, I installed the modified jar in /system/framework and tried it out for around 10 minutes by making the phone lose and regain reception several times and monitoring the logcat. So far, I have not seen any exceptions related to "Too many open files" whenever an android.intent.action.LTE_SMS_STATUS broadcast is attempted.

ADDENDUM: I'm wondering whether the below patch is better. The code will now wait for the am command to complete before destroying the process instance. If we destroy the process instance without waiting for the process to terminate, we could possibly be preventing the process from executing or killing the process during its execution.

diff -purN android_device_samsung_hlte-common/ril/telephony/java/com/android/internal/telephony/hlteRIL.java android_device_samsung_hlte-common_fixed/ril/telephony/java/com/android/internal/telephony/hlteRIL.java
--- android_device_samsung_hlte-common/ril/telephony/java/com/android/internal/telephony/hlteRIL.java	2015-03-06 12:32:07.383431946 -0600
+++ android_device_samsung_hlte-common_fixed/ril/telephony/java/com/android/internal/telephony/hlteRIL.java	2015-03-06 23:24:58.594694004 -0600
@@ -262,7 +262,13 @@ public class hlteRIL extends RIL impleme
Rlog.d(RILJ_LOG_TAG, "Executing AM: " + amString);

try {
- Runtime.getRuntime().exec("am " + amString);
+ Process proc = Runtime.getRuntime().exec("am " + amString);
+ try {
+ proc.waitFor();
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ proc.destroy();
} catch (IOException e) {
e.printStackTrace();
Rlog.e(RILJ_LOG_TAG, "am " + amString + " could not be executed.");