0

When integrating the ETPush SDK in our Android APP, we first ignored the advised approach to put the call to ETPush.configureSdk() into the application's onCreate() method, but rather attaching things to our Dagger object graph lifecycle.

This approach causes reproducible crashes (see stacktrace) after the application is terminated. After moving initialisation to the suggested place, we noticed that there is a mechanism to restart the app from a service that comes with the SDK, which is proven by the fact that we see a new app process spawning (adb shell ps) without being triggered by the user.

Our questions:

  1. What is the exact purpose of insisting on configuring the SDK within onCreate()?
  2. Is there a technical explanation / need for starting the application "magically" by itself?
  3. What would be the recommended approach to fully disable this mechanism in case of unexpected issues without completely removing the SDK and without a new app release?

It feels a bit creepy to have something like that in our app that practically takes full control.

Thanks a lot.

Stacktrace example:

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.mycompany/com.mycompany.ui.activities.MainActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.exacttarget.etpushsdk.ETPush$a.c()' on a null object reference
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3254)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3350)
at android.app.ActivityThread.access$1100(ActivityThread.java:222)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1795)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:158)
at android.app.ActivityThread.main(ActivityThread.java:7229)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.exacttarget.etpushsdk.ETPush$a.c()' on a null object reference
    at com.exacttarget.etpushsdk.ETPush.configureSdk(ETPush.java:296)
    at com.mycompany.business.trackers.SalesForceTracker.<init>(SalesForceTracker.java:133)
    ... more dagger stuff
Improve this question

1 Answer 1

Reset to default
0

The SDK does not start arbitrarily. There are intent-filters which can be seen in the merged manifest. The service will be started and configureSdk() is called. The data stored within the SDK is encrypted and relies on several pieces of information to form its encryption key. Some of those pieces are provided by configureSdk().

As you noted: putting the configureSdk() call in your Application's onCreate() resolves the stacktrace you observed.

Improve this answer
2
  • Thanks a lot for your quick answer. Anyway, one question remains: why does it have to be initialized in onCreate(), why isn't it possible to call configure at a later point? This prevents integrating SDK initialisation in a way that fits the custom lifecycle of a more complex app. Thank you very much!
    – Rage
    Commented Nov 16, 2016 at 10:35
  • The current design instantiates the local SQLite database, which has encrypted columns, such that it can be used by the SDK, its Receivers and its Services. It does this as a result of the configureSdk() call. The encryption key is generated, in part, from your AppID & Access Token.
    – Bill Mote
    Commented Nov 16, 2016 at 21:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .