[Motorola Droid 4] mymegabyte:
Data connectivity on Verizon

I've given these builds a try over the last couple days and the number one issue I've experienced is finicky-ness of data deciding to connect (USA/Verizon, LTE/EvDo/CDMA coverage area).

I've observed many different failure (and success) modes:

Data may come up but shows (falsely) as roaming (confirmed still happened on Stargo's 1130 build)

Data does not come up at all (empty bars)

Data does not come up at all. Phone FCs (confirmed still happened on Stargo's 1130 build)

Data may come up just fine (LTE) (confirmed still happened on Stargo's 1130 build)

Data can be forced into CDMA, EvDo or LTE just fine. (Didn't test on Stargo's 1130)

Booting with phone in LTE only mode prevents data from coming up. (Didn't test on Stargo's 1130)

For each build change I wiped system/data/cache/"dalvik" on the rom slot and reinstalled.

The randomness of it screams race condition to me. After combing through logs... and logs... and logs. I've come up with two commits that seem to make initiating data connections much more reliable.

This one fixes the Phone FC mentioned in observations above.

https://github.com/mymegabyte/andro...mmit/5e4fcc0d3e28487b1d746d99dacfab79180e9dc0

Sample NPE stack trace....

11-30 15:55:29.359 E/AndroidRuntime( 1313): FATAL EXCEPTION: main
11-30 15:55:29.359 E/AndroidRuntime( 1313): Process: com.android.phone, PID: 1313
11-30 15:55:29.359 E/AndroidRuntime( 1313): java.lang.NullPointerException: Attempt to invoke virtual method 'int java.util.ArrayList.size()' on a null object reference
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at com.android.internal.telephony.dataconnection.DcTracker.onDataSetupComplete(DcTracker.java:2455)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at com.android.internal.telephony.dataconnection.DcTrackerBase.handleMessage(DcTrackerBase.java:820)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at com.android.internal.telephony.dataconnection.DcTracker.handleMessage(DcTracker.java:3276)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at android.os.Handler.dispatchMessage(Handler.java:102)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at android.os.Looper.loop(Looper.java:135)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at android.app.ActivityThread.main(ActivityThread.java:5221)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at java.lang.reflect.Method.invoke(Native Method)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at java.lang.reflect.Method.invoke(Method.java:372)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
11-30 15:55:29.359 E/AndroidRuntime( 1313):	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)

This one makes the UNKNOWN and UNINITIALIZED states for the mMncLength variable in SIMRecords functionally equivalent. They are two very similar named constants with two very similar functions. My $0.02 was that in at least one (or all) of those places the other one should have been checked.

https://github.com/mymegabyte/andro...mmit/96e54282ec603e9e027aaae93dcac12268095e38

Since applying my two commits:

When I set my preferred network type to "CDMA+LTE/EvDo" and rebooted. I did get stuck with the "R" for roaming. But data worked.

When I left preferred network type as "Global" and rebooted. The network came up in LTE mode as expected.

In general getting a non-roaming data connection seems much more reliable.

These commits haven't been tested exhaustively and may be placebos or bandaids for some bigger issue. Just so far the results seem positive. If anybody else is experiencing similar issues (to the observations) it may be worth noting to see if Stargo wants to give them a try.

Thank you for your hard work Stargo.