Snowplow Android not sending events

For engineers Tracking SDKs
1

I have a problem with the Snowplow Android Tracker.

I create the events call and checking my log it works fine, but the Snowplow not send the events for my back end.

I look the Snowplow database and it is populate right.

Follow my code when I build the emitter and tracker:
private Emitter buildEmitter() { return new Emitter .EmitterBuilder(emitterUrl, getContext()) .method(HttpMethod.GET) .security(RequestSecurity.HTTP) .tick(2) .timeUnit(TimeUnit.MINUTES) .callback(callback) .build(); }

private Tracker buildTracker() { Tracker tracker = new Tracker .TrackerBuilder(buildEmitter(), "br.digitalpages.com.br/mobile", getAppId(), getContext()) .base64(false) .platform(DevicePlatforms.Mobile) .level(LogLevel.VERBOSE) .build(); return tracker; }

I’m using the 0.5.4 of the snowplow classic tracker.

I included the callback but it not called and I connect the Charles proxy and check if my events is hiring, but not was sent.

I wonder if anyone can help me ?

Thanks!

2

Hi @delmanoPedro, what does get logged from the Tracker so far when you send an event into the Tracker?

Also please note that setting the tick(2).timeUnit(TimeUnit.MINUTES) means that in the event the Emitter cannot see any events in the database it will wait a full two minutes before attempting again. To speed up debugging I would remove both of those builder options so the Emitter attempts to send and query more often.

3

HI @josh I try this but not was sent yet.

The log not show error.

4

What logs are being shown? Could you paste those here?

Could you also paste in the full code for the Tracker + Emitter creation.

5

The code of the Tracker + Emitter is this:
private Emitter buildEmitter() { return new Emitter .EmitterBuilder(emitterUrl, getContext()) .method(HttpMethod.GET) .security(RequestSecurity.HTTP) .callback(callback) .build(); }

private Tracker buildTracker() { Tracker tracker = new Tracker .TrackerBuilder(buildEmitter(), "br.digitalpages.com.br/mobile", getAppId(), getContext()) .base64(false) .platform(DevicePlatforms.Mobile) .level(LogLevel.VERBOSE) .build(); return tracker; }

Follow the log:

V/SnowplowTracker->Util: pool-10-thread-4|Converting a map to a JSONObject: {uid=7077235, res=800x1280, co={“schema”:“iglu:com.snowplowanalytics.snowplow/contexts/jsonschema/1-0-1”,“data”:[{“schema”:“iglu:br.com.digitalpages/dp_client_context/jsonschema/1-0-0”,“data”:{“system_id”:“40”,“institution_id”:“1432”}},{“schema”:“iglu:com.snowplowanalytics.snowplow/mobile_context/jsonschema/1-0-0”,“data”:{“deviceModel”:“GT-N5110”,“androidIdfa”:“ce14a1b5-7c75-4871-a5e4-a929a6505f97”,“osType”:“android”,“osVersion”:“4.4.2”,“deviceManufacturer”:“samsung”}}]}, dtm=1463150304960, tz=America/Sao_Paulo, e=ue, tv=andr-0.5.4, p=mob, tna=br.digitalpages.com.br/mobile, aid=aridesa_mobile/0.0.1, lang=português, eid=ee0fa841-863f-41be-af8f-3b97685c954f, ue_pr={“schema”:“iglu:com.snowplowanalytics.snowplow/unstruct_event/jsonschema/1-0-0”,“data”:{“schema”:“iglu:br.com.digitalpages/dp_publication_event/jsonschema/1-0-1”,“data”:{“category”:“reading”,“publication_id”:“50850”,“elapsed_time”:1584,“page”:“4145062”,“name”:“download_page”}}}}

V/SnowplowTracker->Tracker: pool-10-thread-4|Tracking Unstructured Event: {“uid”:“7077235”,“res”:“800x1280”,“dtm”:“1463150304960”,“co”:"{“schema”:“iglu:com.snowplowanalytics.snowplow\/contexts\/jsonschema\/1-0-1”,“data”:[{“schema”:“iglu:br.com.digitalpages\/dp_client_context\/jsonschema\/1-0-0”,“data”:{“system_id”:“40”,“institution_id”:“1432”}},{“schema”:“iglu:com.snowplowanalytics.snowplow\/mobile_context\/jsonschema\/1-0-0”,“data”:{“deviceModel”:“GT-N5110”,“androidIdfa”:“ce14a1b5-7c75-4871-a5e4-a929a6505f97”,“osType”:“android”,“osVersion”:“4.4.2”,“deviceManufacturer”:“samsung”}}]}",“e”:“ue”,“tz”:“America/Sao_Paulo”,“p”:“mob”,“tv”:“andr-0.5.4”,“tna”:“br.digitalpages.com.br/mobile",“aid”:“aridesa_mobile/0.0.1”,“ue_pr”:"{“schema”:“iglu:com.snowplowanalytics.snowplow\/unstruct_event\/jsonschema\/1-0-0”,“data”:{“schema”:“iglu:br.com.digitalpages\/dp_publication_event\/jsonschema\/1-0-1”,“data”:{“category”:“reading”,“publication_id”:“50850”,“elapsed_time”:1584,“page”:“4145062”,“name”:“download_page”}}}”,“eid”:“ee0fa841-863f-41be-af8f-3b97685c954f”,“lang”:“português”}

6

Can someone help me?

7

Hi @delmanoPedro, what we need to look for in the logs are any errors that are occurring while running the tracker. As well as key lines that could point to where we are getting to in the Tracker; specifically logs from this function that does the actual sending.

Are you building the Tracker as a Singleton object - making one Tracker for the life of your application?

If NO for the above are you creating the Tracker in some form of Async task which could be killing the Tracker before it has a chance to send?

If you could please provide some more context around how you are using the Tracker we should be able to figure out what is going wrong!

Cheers,
Josh

8

Hey @josh , thanks for your reply.
Checking the method that you told, actually he’s never called.
The process “stop” at addPaylod method where has a validation to check if the emitter it is not currently running, but the validation isn’t true, so don’t call the attemptEmit to really send the event.

I haven’t figured out the real problem, I hope you can help me.

Best,
Pedro Delmano

9

Hi @delmanoPedro sorry for the slow turn around on replies! That is very strange that it is not getting into that loop. The only other thing that would prevent the Tracker from getting into that loop would be if it detects your device as being offline.

It would also be helpful to run the demo app that we distribute on the device to see if it is able to send properly - to ensure that it is not a device specific problem. You can install this with the guide here: https://github.com/snowplow/snowplow/wiki/Android-Tracker#demo-app

10

Hi @josh I look my code and debug the app.

I found the problem, I’m using okhttp3 and the Snowplow uses okttp and this cause conflict.

In this way, the SDK don’t build de url for send events.

Do you have any idea about this?

Thanks

11

Hi @delmanoPedro for the moment you will need to import OkHttp2 along with OkHttp3. The next release of the Android Tracker will bring support for OkHttp3.

Are you currently importing both?

12

Hi @josh I’m importing both, but the flow broken in requestBuilderGet in the moment of return method, but the log not show error.
I don’t understand why this occurs.

private Request requestBuilderGet(Payload payload) {
        addStmToEvent(payload, "");

        // Clear the previous query
        uriBuilder.clearQuery();

        // Build the request query
        HashMap hashMap = (HashMap) payload.getMap();

        for (String key : (Iterable<String>) hashMap.keySet()) {
            String value = (String) hashMap.get(key);
            uriBuilder.appendQueryParameter(key, value);
        }

        // Build the request
        String reqUrl = uriBuilder.build().toString();
        return new Request.Builder()
                .url(reqUrl)
                .get()
                .build();
    }
13

It might be swallowing the error as it is running in a background thread. Does event sending work if you use POST rather than GET requests?

14

I tried the POST method but does not work too. Do you know when will be released the new version of the SDK, using okhttp3?

15

We do not have an ETA beyond that it should be happening in the next release.

Are you using Proguard in your build process? I am wondering if there could be a strange conflict with Proguard and having both OkHttp libraries included.

If you do have Proguard enabled would you be able to try a build without?

16

I removed proguard from my build and not work.

I don’t understand this problem.

The flow work perfectly, but broken in Request.Builder and not generate exception.

17

It is really strange that is is not working. Following from that point it should end up inside this function:

https://github.com/snowplow/snowplow-android-tracker/blob/master/snowplow-android-core/src/main/java/com/snowplowanalytics/snowplow/tracker/Emitter.java#L339-L347

Are you seeing the logging from line 341 at all?

18

This method is never called.

I believe it is not riding the requests.