Adobe Experience Platform Mobile SDKs – Debugging

This article is part of the Adobe Experience Platform Mobile SDKs mini-series. It is about debugging your app.

You can find the overview here.

Today, we’ll talk about an aspect of development that, on mobile apps, is a royal pain, at least compared to the browser-based and extension-supported debugging we do when we deploy on web sites.

Project Griffon

When you work with Javascript and a tag manager, the Console in your browser is an easy and powerful way to debug. On top, you have a multitude of extensions helping you with your work.

In contrast, to debug mobile apps, most cases involve man-in-the-middle type approaches, like using Charles to check on the traffic sent by the app.

Project Griffon” is a different approach altogether, currently in beta, involving a web service with user interface, plus a Launch Extension that you compile into your app.

The Project Griffon Extension can connect to the web service, and it can report everything that happens within the Experience Platform Mobile SDKs, so you can easily analyse it in the UI. You can also export your debugging sessions to JSON for analysis in other tools.

Now you know why we had to look at deep linking: launching your app via deep link will tell the Extension to record to the service, and it allows the Extension to connect to a specific “session” (you’ll see)

So, let’s do this!

Extension & Coding

As usual, find the Extension in the Catalog in your mobile Property in Launch

Add the Griffon Extension via the Catalog
Add it to a Library, then publish that Library all the way through.

In Android Studio, add the usual code snippets to your build.gradle and

Added code in Launch – part 1
Added code in Launch – part 2
Rebuild the app, and you’re good to go.


With your app deployed on the emulator or (better) your phone, it is time to use Griffon.

Log into it using (not on your desktop.

First time in Griffon
Use the “Create Session” button to start a little wizard.

Create Wizard – start
Hit “Start”

Name the session and provide the deep link
Give your session a name, and put in the URL that you specified when you made the deep link. Make sure you use the correct URL! Mine was http, not https, and that does matter.

When you click “Next”, Griffon shows you a deep link and QR code. Use these to start your app on your emulator or mobile device.

You’ll see a 4-digit pass code a bit further down, which you must enter on your device for authentication.

Enter the code on your device
Creation complete
That’s it, your app is connected, and Griffon can see everything the SDK sends.

Debugging — in App

The first thing you’ll notice in your app is a big Griffon logo in the top right corner.

You can move that logo around, in case it is on top of any UI element you want to use or test.

Griffon logo can be moved
If you tap the logo, you get to the Griffon screen, which shows you a condensed view of what you can see in the Griffon UI, too.

On-device view
You can also, here, disconnect from Griffon.

Debugging — the UI

The Griffon Web UI is more powerful.

Active Session – Web UI
You’ll see a list of events that Griffon received from the app.

That list will update when you do something in/with the app.

Tapping the “email” icon button at the bottom right in the app, as an example, leads to Target replacing two parts of the screen (we built that in the article about Target), and some tracking (we built that in the article about Analytics).

You can see all of that traffic in the list, immediately.

Events as a result of tapping the icon
You can see the data that was sent to Analytics

Analytics hit payload
And you can see what Target sent back to the app

Target response
Cool, right?

Debugging — Analytics

Griffon has specific views, too, for Analytics and Places. You access those via the “Home” menu.

The menu behind Home
Select Analytics and the view changes radically.

First of all, all non-Analytics messages are hidden. Second, you can see information regarding the event more easily, such as the state name for trackState calls, and context Data that is passed. And third, some of the events are “queued”

Queued Analytics hits
After a bit of time, some or all of them will change to “processed”

Processed Analytics hits
What happens here is that Griffon goes and tries to pull the hit back out of Analytics, so it can show you what actually went through.

I consider this extremely useful!

Update 2020-03-03 – you can read more on this in the next article


Places, too, has a UI in the Griffon web UI.

You can see the requests go out

Places request
And you can see what POIs are being sent back by Places

Places response
You can also check the Places traffic right in your app, when you tap the Griffon icon:

Places events in app
The official documentation for Project Griffon is online, even though at the time when this article goes live, Griffon is still beta.

I do NOT know when it’ll be generally available, but I hope it will be soon.

I also do not know whether there will be more dedicated “decoders”, e.g. for Target or any other application or Extension.

There is “Custom Validation”, which you can use to build your very own “decoder”. There might be an article about this at some point, but for now, may I direct you to the official documentation for this feature?

Custom Validation for events
And may I point out that you can manage those “decoders” via gists?

Certainly looks interesting!

3 thoughts on “Adobe Experience Platform Mobile SDKs – Debugging

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.