skip to content

Server and Device Logs

3 roadmaps4 questions

The Appium server's own log and the flags that shape it, plus the device log buckets pulled through the log endpoints - named differently on Android and iOS, and re-pathed in Appium 3.

on this pageshow

explore

questions

4

In Appium, which request pulls a device log, and which log types exist on Android versus iOS?

level: middleimportance: must knowfreq 58%

answer

  1. one route, two platform vocabularies
  2. session-scoped, not a file on disk
  3. Appium 3 moved it under se/
  4. discover the types before naming one

basics

~20 s

Appium pulls device logs with POST /session/:sessionId/se/log, naming a type in the body. The Android drivers offer logcat and bugreport; the XCUITest driver offers syslog, crashlog and safariConsole. GET /session/:sessionId/se/log/types lists what a driver serves.

solid answer

~40 s

Device logs come out of a live session over `POST /session/:sessionId/se/log`, whose body names one log type, and `GET /session/:sessionId/se/log/types` returns the type names that session's driver actually serves. Appium 3 re-pathed both under the `se/` prefix — its migration guide maps `/session/:sessionId/log` and `/session/:sessionId/log/types` onto them — so target the `se/` forms. The type names do **not** cross platforms: the Android drivers publish `logcat` and `bugreport`, while the XCUITest driver on Apple platforms publishes `syslog`, `crashlog` and `safariConsole`. A cross-platform helper therefore cannot hardcode one name; it discovers the list per session or branches on `platformName`. Both routes are session-scoped, so they only answer while the session is alive.

code

bash · 15 lines
bash
SESSION_ID="$1"
BASE="http://127.0.0.1:4723"

# 1. Ask this session's driver which log types it serves
curl -s "$BASE/session/$SESSION_ID/se/log/types"

# 2. Android lane: pull the caving trip-log app's system log
curl -s -X POST "$BASE/session/$SESSION_ID/se/log" \
  -H 'Content-Type: application/json' \
  -d '{"type":"logcat"}'

# 3. Apple lane: the same route, a different type name
curl -s -X POST "$BASE/session/$SESSION_ID/se/log" \
  -H 'Content-Type: application/json' \
  -d '{"type":"syslog"}'

go deeper

for a junior

Know that a device log comes out of the running Appium session over an HTTP call, not off the host disk. Be able to say that the type you ask for is named differently on Android than on Apple platforms.

for a middle

Be ready to name both routes, explain that the type list belongs to the driver rather than the protocol, and say which spelling Appium 3 expects after the log routes moved under the se/ prefix.

for a senior

Show that you discover types per session instead of hardcoding one, and that you pull while the session id still resolves. Be able to say which bucket answers which kind of question on each platform.

for a principal

Own where the platform branch lives. Decide which log surfaces your driver layer exposes at all, and keep an Android-only bucket name from leaking into shared suite code that also runs on Apple devices.

## The two routes, and what session-scoped means Appium exposes device logs as HTTP on a live session rather than as files you go and hunt for on the host. Two routes matter. `POST /session/:sessionId/se/log` takes a body naming one **log type** and returns that bucket's entries. `GET /session/:sessionId/se/log/types` returns the list of type names the driver behind that session is prepared to serve. Both hang off a session id, and that has a consequence people trip over: they answer only while the session exists. If a run ends the session and *then* decides it wants the device log, the door is already shut. The `se/` segment is the Selenium-extension prefix and it is the current spelling. Appium 3's migration guide maps `POST /session/:sessionId/log` onto `POST /session/:sessionId/se/log`, and `GET /session/:sessionId/log/types` onto `GET /session/:sessionId/se/log/types`, so new client code should be written against the `se/` forms. Note the parameter spelling as well: Appium's route tables write `:sessionId`, never `:id`, which matters the moment you build a URL by hand or grep a client for one. ## The type names belong to the driver, not to the protocol This is the part that produces broken cross-platform helpers. There is no protocol-level list of log types that every mobile driver implements. Each driver publishes its own, and the two platforms share none of them. | what you are after | Android drivers (UiAutomator2, Espresso) | XCUITest driver (Apple platforms) | |---|---|---| | the device's rolling system log | `logcat` | `syslog` | | crash detail after the app dies | `bugreport` | `crashlog` | | a web view's console output | not offered under these names | `safariConsole` | Concretely: - `logcat` and `bugreport` are **Android** type names, served by the Android drivers, so a UiAutomator2 session and an Espresso session both offer them. - `syslog`, `crashlog` and `safariConsole` are the **XCUITest driver's** names on Apple platforms. - Not one name crosses. A helper that asks an Apple session for `logcat` is naming a type that driver does not publish, and it will not quietly degrade into an Android-shaped answer. - Because the list is the driver's, the only honest way to know it for a given session is to ask that session. ## Why the discovery call earns its round trip `GET /session/:sessionId/se/log/types` looks like ceremony until you run more than one platform. It buys three things: 1. **Correctness without a lookup table in your head.** The session tells you what it serves, so you are not maintaining a private copy of two drivers' vocabularies inside your suite. 2. **A safe failure.** If the type you were about to ask for is not in the returned list, you can skip the pull and say so, instead of firing a request built on a name that platform never had. 3. **Room for a driver you have not met.** Android and Apple are the two lanes you deal with daily, but the mechanism is per-driver, so any other driver's list is simply whatever it publishes. ## A worked example: the caving trip-log app Suppose a caving trip-log app records a survey leg, and the step that saves the leg fails on both lanes of your matrix. The shape of the fix is the same on both; the identifiers are not: - On the **Android** session, ask for `logcat` to see the app's own output around the failure, and `bugreport` when you need the wider device state that came with it. - On the **Apple** session, ask for `syslog` for the system-side stream, and `crashlog` when the trip-log process itself went away. - If the trip-log app renders its survey notes in a web view on Apple platforms, `safariConsole` is the bucket that carries that view's console output; the Android list above has no bucket under that name. - Do all of it **before** the session ends, because the routes are keyed by session id. ## The mistake this design invites The endpoint being uniform while the vocabulary is not is exactly the trap. An author writes the helper on Android, it works, and the same helper is later pointed at an Apple session where the URL resolves perfectly well and the type name does not. Nothing about the route warns you; the divergence lives entirely in the request body. The second common mistake is timing — pulling after teardown, when the session id no longer addresses anything. The third is assuming a device log is something you fetch from the host rather than from the session; the session route is what an Appium suite actually has, and it is what still works when the device is not the one on your desk. Treat the device log as something you take out of a session while it is open, name per platform, and never assume the name you learned on one lane exists on the other.

  • What does GET /session/:sessionId/se/log/types return, and why call it before se/log?
    It returns the log-type names the driver behind that session actually serves — `logcat` and `bugreport` from the Android drivers, `syslog`, `crashlog` and `safariConsole` from the XCUITest driver. Calling it first turns a guess into a lookup: it is the only portable way to pick a valid type name, and it lets a helper skip the pull cleanly when the bucket it wanted does not exist on that platform.
  • Your caving trip-log helper asks an Apple session for logcat. What happens, and what is the fix?
    You do not get an Apple device log: `logcat` is an Android drivers' name and the XCUITest driver publishes nothing under it, so the request cannot be served. Fix it in the helper, not at the call site — read `platformName`, or call `se/log/types` for that session, and map your suite's abstract idea of a device log onto `logcat` on Android and `syslog` on Apple platforms.
  • Why is it wrong to pull the device log in an after-suite hook?
    Both log routes are addressed by session id, so they answer only while the session is alive. An after-suite hook typically runs once every session it cares about has already been deleted, and the entries are then unreachable through Appium. Pull inside the per-session scope, while the id still resolves.

Asking a session for a log type is like ordering from a menu: the driver hands you its own menu, and the Android menu and the Apple menu share no dish names.

saying these in an interview costs you the question

  • Thinks logcat is Appium's log type on every platform
  • Assumes the log type list is the same on Android and iOS
  • Reads device logs off the host filesystem instead of the session
  • Still writes POST /session/:sessionId/log without the se/ prefix
  • Expects to pull a session's logs after the session has ended
  • Believes an unknown log type quietly returns an empty list
open as a page

In Appium, how do you capture a caving trip-log app's crash output on Android and on iOS?

level: seniorimportance: should knowfreq 39%

basics

~20 s

Pull it through the session. On Android the drivers serve logcat and bugreport over POST /session/:sessionId/se/log; on Apple platforms the XCUITest driver serves crashlog and syslog. The Android drivers also stream live through mobile: startLogsBroadcast.

open as a page

Which Appium server flags decide where the server's own log goes and how much it carries?

level: seniorimportance: should knowfreq 46%

basics

~20 s

The Appium server's own log is shaped by server flags: --log-level sets verbosity, --log sends the stream to a file, and --log-timestamp prefixes each line. That one stream carries every session the process handles, Android and Apple alike.

open as a page

Why can one Appium log configuration not serve an Android and an iOS lane, and what do you standardise?

level: principalimportance: should knowfreq 31%

basics

~20 s

Appium's logging has two halves. Server flags such as --log-level and --log are process-wide and identical for both lanes; device log type names belong to the driver and share nothing across platforms. Standardise the first, discover the second.

open as a page