OkLog 2.0 — improved Android network logging

Simon Percic
ProAndroidDev
Published in
4 min readDec 1, 2016

--

In my previous article, “Effortless network response logging on Android”, I have outlined the different approaches to network response logging when using two de facto networking libraries from Square: Retrofit and OkHttp.

I have also presented my own approach, a library named OkLog. It acts as a OkHttp network interceptor that prints a clickable link to Android logcat, which looks something like this:

Example of a link created by OkLog

That link has the network response encoded directly in the URL itself. Clicking the link opens a website with the plain response so you can inspect the received data.

Since then, I completely rewrote OkLog, enabling it to show a lot more data about a network call than just the plain response body.

OkLog 2.0 is now able to show all of the network request and response data that is printed to logcat by OkHttp’s own Logging Interceptor, which OkLog is inspired and based on.

OkLog 2.0 in action

OkLog 2.0 in action

See it in action in this live example.

The generated link now points to a website that looks something like this:

OkLog 2.0 response info

OkLog 2.0 now shows additional data, including:

  • request url
  • request method (GET, POST, PUT, DELETE, etc.)
  • request body
  • request headers
  • request content type and length
  • request failed / success state
  • response code and message
  • response duration
  • response size
  • response headers
  • response body

See this overview table on the GitHub repo for a list of all the available options and to see which are included by default.

The request and response bodies are embedded directly on the info page. Both of them have a “show plain body” link above them. Clicking it shows the plain body, which is pretty-printed if it’s a JSON (since that’s what you’re probably using).

Request and response headers are not included by default, since the headers usually include auth tokens which might present a security risk. You can, however, include them easily when you create an instance of the OkLogInterceptor via its Builder.

Url shortening

Sharing network call details with your coworkers (and backend API developers) is made easier by OkLog, since you can just grab the link and share it. That way anyone with the link can see the request that was made and its response.

With OkLog 2.0 sharing got even easier by integrating url shortening via goo.gl.

You can now shorten an url by clicking on the “shorten” button on the bottom of the response info page:

Shorten url button on the bottom of the page

You can also set an option of the OkLogInterceptor Builder that will cause all of your links to be shortened on the server-side, but only once they are opened:

shortenInfoUrl(true|false) // defaults to false

Keep in mind

Since the request and response data is included in the URL itself, shortening it by using an external service means the data is consequently implicitly stored by the url shortening service provider. If you’re concerned about that, I strongly suggest you don’t use url shortening.

How does it work

OkLog intercepts network data from OkHttp, which it then packs into an URL link. That link is then logged to Android’s logcat.

The URL points to a hosted instance of the ResponseEcho web app that does the exact opposite, i.e. unpacks the URL params and displays the data on a website.

Encoding data into the url

The response body is gzipped and Base64 encoded and appended to the URL as a path param. The same happens for the request body, which is instead added as a query param.

All the other request and response data (like headers, request url, duration, size, etc.) is serialized using a predefined schema with Protocol Buffers. After that, it’s gzipped and Base64 encoded so it can be included as a query param in the generated URL. Due to its efficiency, ProtoBuf ensures the data takes up as few bytes as possible, which helps when creating an URL.

Square’s Wire implementation is used for serializing and deserializing ProtoBuf messages transmitted between OkLog and ResponseEcho. The Proto scheme is shared between the two projects to ensure stable serialization and deserialization.

Privacy

OkLog in combination with ResponseEcho are able to work by encoding request and response data in the URL path and query parameters.
Consequently, this data might be intercepted on the network.

If you’re concerned about your request and response data being intercepted, I strongly suggest you self-host ResponseEcho and set OkLog to point to your hosted instance (either locally or on your own server).

Try it out

OkLog is open source, licensed under the MIT license and available on GitHub. Check it out for more info and how to use it in your Android app.

--

--