NetworkInfoReceiver.isNetworkConnected() on a null object reference

[suyangdong]

Hi, I am not entirely sure if this problem is in the SDK or my code? I upgraded to 2.2.14.
Could you help make a judgement?

I do want to point out though this problem doesn't occur under stable WiFi network (I have already tested it under WiFi for more than 24 hrs taking tens of thousands photos without glitch).

It happens frequently under 4G network (the single is weak, on and off from time to time). The crash hit me at least four times over the past 24hrs.

Thank you!

java.lang.NullPointerException: Attempt to invoke virtual method 'boolean com.amazonaws.mobileconnectors.s3.transferutility.TransferService$NetworkInfoReceiver.isNetworkConnected()' on a null object reference
at com.amazonaws.mobileconnectors.s3.transferutility.TransferService.execCommand(TransferService.java:287)
at com.amazonaws.mobileconnectors.s3.transferutility.TransferService$UpdateHandler.handleMessage(TransferService.java:224)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)

[fosterzhang]

So unstable network only? Investigating.

[suyangdong]

Correct. I have been hit again by the same crash message this morning under shaky cellular network. The same program running on other three devices under WiFi network performed like a champion.
I switched back to 2.2.13 to see if it would make any difference.

TransferUtility does a very good job to resubmit workload that fails under offline status, when the network comes back online. However, I do notice that sometimes the online/offline event broadcast by the Android OS isn't very reliable under shaky cellular network. I am not sure if this observation is relevant here or not.

[suyangdong]

Hi, I don't know if this fact helps or not. But under the SDK 2.2.13, the program has been running close to 24hrs without being hit by the same error message.

I am not sure if the cellular signal strength has improved or not since the replacement of 2.2.14, which I doubt, and the same smart phone has been placed at the same location for testing.

I will let you know if it is hit by the error again.

Thanks.

[fosterzhang]

@dsuyang working on it. Please use v2.2.13 at the moment.

[suyangdong]

Thank you. Yes, I ran 2.2.13 close to 72hrs without any glitch.

[riandyrn]

Hi,

I'm also experiencing the same issue. Only in my case it happens when transfer utility service trying to restart itself after deep sleep. Glad I found this thread. I will use v2.2.13 for now.

Thanks a lot for opening this thread @dsuyang !

[suyangdong]

Hmmm... I am not sure any more if it is safe to use v2.2.13, because my app has been hit by the error multiple times yesterday even under 2.2.13.
I know it is very weird... never happened before, but it does now and very frequently.... I wonder if it is because I changed my code and made it more vulnerable to the problem.

[jiraya85]

I have the exact same problem when I try to upload an image to an s3 bucket. Sometimes (apparently in a random interval) this problem occurs. I'll try to use the 2.2.13

[broakenmedia]

Same issue here. Actually seems to be related to the Transfer Utility not initialising fully by the time i attempt to upload an image. I.e if i open the app, then quickly move to uploading an image, unless i wait a few seconds, it'll crash with the above

[briandilley]

The workaround that i posted here seems to work for me: http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash/36710233#36710233

Essentially this:

/**
 * work around for a bug:
 * http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash
 */
public static void startupTranferServiceEarlyToAvoidBugs(Context context) {
    final TransferUtility tu = new TransferUtility(
            new AmazonS3Client((AWSCredentials)null),
            context);
    tu.cancel(Integer.MAX_VALUE - 1);
}

in your application's onCreate

[broakenmedia]

That's actually what I'm already doing, does not seem to have improved an already occasional crash however

On 19 Apr 2016, at 7:33 am, Brian notifications@github.com wrote:

The workaround that i posted here seems to work for me: http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash/36710233#36710233

Essentially this:

/**

• work around for a bug:
• http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash
  */
  public static void startupTranferServiceEarlyToAvoidBugs(Context context) {
  final TransferUtility tu = new TransferUtility(
  new AmazonS3Client((AWSCredentials)null),
  context);
  tu.cancel(Integer.MAX_VALUE - 1);
  }
  in your application's onCreate

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[briandilley]

It has completely fixed the crash for us at Flipagram. We deployed it with
our 6.0.10 version and it hasn't happened a single time since.
On Apr 18, 2016 11:40 PM, "Joe Scott" notifications@github.com wrote:

That's actually what I'm already doing, does not seem to have improved an
already occasional crash however

On 19 Apr 2016, at 7:33 am, Brian notifications@github.com wrote:

The workaround that i posted here seems to work for me:
http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash/36710233#36710233

Essentially this:

/**

• work around for a bug:
  *
  http://stackoverflow.com/questions/36587511/android-amazon-s3-uploading-crash
  */
  public static void startupTranferServiceEarlyToAvoidBugs(Context
  context) {
  final TransferUtility tu = new TransferUtility(
  new AmazonS3Client((AWSCredentials)null),
  context);
  tu.cancel(Integer.MAX_VALUE - 1);
  }
  in your application's onCreate

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#117 (comment)

[fosterzhang]

This is fixed in v2.2.15. See release notes.

[suyangdong]

Thank you! Gonna try it out this evening.
Edit: [So far so good, after one night of experiment.]