Something interesting to note is that every call to logs().get('logcat') will only return log entries since the last time logs().get('logcat') was called. The logs are returned as a LogEntries class which implements the interface.Ī single LogEntry object has toString() and toJson() methods, as well as some methods to get individual parts of the message such as timestamp or log level. We are looking for 'logcat' logs, but notice that Appium also provides android bug report data. The first method returns a collection of Strings which represent the logs which Appium provides. The Python client and WebdriverIO call the same methods this way: driver.log_types # note this is a property, not a function Which can be called using the following methods in the Java client: driver.manage().logs().getAvailableLogTypes()

Or maybe the only way to assert that our test succeeds is to make sure a particular pattern appears in the logs.Īndroid systems make these logs available using a tool called logcat, and Appium clients can access these logs remotely.īoth Appium and Selenium respond to the following JSON Wire Protocol endpoints: GET /wd/hub /session/:sessionId /log/types Maybe our test failed and we want to see if our app logged an error to the system.

An Android device or emulator records detailed system logs, which can sometimes contain information which is pertinent to a test.

Appium server logs off