Noob Story — Don’t forget to check on Android Studio Log File
Today is the weekend and I was installing android development setup on my new laptop. It was pretty solid at first. Installing git, android studio, visual studio code, jdk and so on.
After installing everything, it is time to load my current ongoing project.
As usual, project source code are already in the git and hosted in github. Pretty straight forward. Set up ssh and cloning everything. For each project, go to the ongoing branch, run at least one time in order to download necessary gradle version used in each project and finally be ready for tomorrow.
My mind was in peace until one project gave me this error.
It always occur many times during my development lifetime. So I was just click “Try Again”. Who knows it can work next time LOL.
Then nothing had changed and still gave me that error. So I had to open build tab, checked the error message. But it shows “Build Successful” in build tab. I was amazed at first. How the project could be built successful in build tab and then show error like the picture above.
Next, I checked on event log and it show like this
Great no detail information. I don’t know where to start finding.
I knew this project work in other laptop. I wrote on last Friday. So the error might not be coding error. It might be somewhere in the android studio config. But sadly no information is provided so far.
At first, I thought, build tab didn’t give me enough error message. So I used command line to build the entire project.
Open terminal tab and just run
And it also success. Wait what, building the project always success and editor didn’t work. You can’t use any IDE related feature in code editor. But whatever you build project in the command line, it success.
I did everything like any android developer will do.
- Invalidate Cache/Restart
- Delete entire project, re-download everything
- Delete ./gradlew folder and redownload
- Change jdk file path and test with different jdk version
- Try running other project and it work on editor as well.
It took more than one hour of my beautiful weekend on googling.
I even used noob way like searching with “Gradle sync failed: Sync failed: reason unknown” keyword. Nothing found so far.
I started panic and didn’t know what is the error root cause.
But luckily someone in stackoverflow in different question enlighten me, there is log file for android studio to log every error. Log file is located in these location.
or clicked “Show Log in Finder” when build failed
So I opened that file with the visual studio code and saw a lot of log in which I couldn’t read so far.
Then he also suggest try to search Error keyword and read what is written in there.
So I searched with
keyword and found 370 search result. I went to the latest result and saw like this.
The root cause is platform ‘android-29’ sdk not found.
Solution is easy, just open sdk-manager and download sdk version 29 and problem is solved.
The problem is android studio didn’t provide that error on somewhere in the event log and build tab
So when you face something similar like that or any uninformative error received in android studio log cat. Don’t forget to go check on log file. It has more information in which you can debug more easily as well.
Here is my tips.
Find with the keyword
On search result, go to the latest result and you can see what is happening in there.
Как найти логи на андроид студии?
Я попытался импортировать свой проект в андроид-студию. Ошибка будет показана. Мне нужно знать, где я могу получить журналы?
9 ответов
На панели инструментов → Меню справки → Показать проводник журнала.
Он открывает папку журнала, где вы можете найти все журналы
У меня была такая же проблема, и после некоторых поисков я смог найти свои журналы в следующем месте:
На Mac, идея .log содержится в
Новая стабильная версия (1.2) находится в
Новая стабильная версия (2.2) находится в
Невозможно получить журналы для установки проблем.
Моя Android Studio 3.0, пожалуйста, следуйте двум шагам ниже, надеюсь, что это поможет;) 
Надеюсь, это поможет кому-то: в Mac OS X журналы находятся в пределах /Users/<user>/Library/Logs/AndroidStudio<version>/
В версии Windows
вы можете найти журнал в нижней части IDE, нажмите «Gradle Console», а затем выберите «Android Monitor». Вы увидите элемент управления Droplistbox, который показывает значение «Verbose» в качестве значения по умолчанию.
Если вы используете log.v() . Подробный вариант в порядке. если вы используете log.d() , просто измените его на Debug.
Итак, когда вы запускаете свой эмулятор, вы можете ловить свой журнал из этого окна.
В ubuntu он должен находиться под
где имя_пользователя зарегистрировано в имени пользователя и product_name может быть, например,.AndroidStudio1.5
How to find the logs on Android Studio?
I have tried to import my project to Android Studio and I got this error. I need to know where I can get the logs.
15 Answers 15
On toolbar -> Help Menu -> Show log in Explorer or Show log in Finder (for Mac users).
It opens log folder, where you can find all logs.
On a Mac, the idea.log is contained in
The new stable version (1.2) is in
The new stable version (2.2) is in
The new stable version (3.4) is in
(From auspicious99 comment) On MacOS Catalina and Big Sur (at least), Android Studio 4.1, the idea.log can be found in,
I had the same problem and after some searching I was able to find my logs at the following location:
My Android Studio is 3.0, please follow the two steps below,hope this will help;) 
Just because none of these pointed to the correct location on my Win10 system
There is no way to get the logs for installing problems.
Had a hard time finding the logs because the IDE was crashing on launch, if you are on Mac and use Android Studio 4.1 then the logs location may be found at /Users/
And to be specific for me it is on macOS Big Sur
Android Studio find a log
In my case it is:
You could open Messages or Event Log tool window to see your log. In addition to that if you want to see device log then you could open Logcat tool window to view your log : View > Tool Windows > Logcat 
Hope this helps someone: on Mac OS X, the logs are within /Users/<user>/Library/Logs/AndroidStudio<version>/
The path to the log files in Windows has been moved.
They appear to be under C:\Program Files\Android\Android Studio\caches\trunk-system\log\idea.log in Android Studio 4.1.1
If you got here because you can’t start an emulator and Android Studio gives you that error message:
- kill qemu-system-x86_64.exe and adb processes
In ubuntu it should be under
where user_name is logged in user name and product_name could be e.g. .AndroidStudio1.5
In windows version
you can find the log in the bottom of the IDE, click the «Gradle Console», and then choose the «Android Monitor». You will see a Droplistbox control which shows «Verbose» as a default value.
Name already in use
android / android / docs / logging.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
IDE logging system
Logging in the IDE is based on the com.intellij.openapi.diagnostic.Logger class. This is an abstraction layer that allows different logging libraries (or their configurations) to be chosen by the IDE, without affecting most of the code. In the current setup, Log4J is used by the IDE at runtime. For details, see IdeaLogger , LoggerFactory and StartupUtil.prepareAndStart .
Logging is configured slightly differently during testing, where additional output is produced at the end of the test run and separate files are used. See TestLoggerFactory .
Configuration for the logging system can be found in log.xml . By default all messages with level INFO and above are written to the log file, idea.log . When running Studio locally, you can find it under tools/idea/system/log . Warnings are additionally written to standard output and errors are made visible to the user by flashing a red icon in the status bar. See the section below for details on how to use the DEBUG level.
When you start Studio from IntelliJ, the run configuration will open two tabs in the Run/Debug tool window: «Console» and «idea.log». The former displays standard output (and thus all warnings), the latter the full log (note that there’s UI there to filter displayed log entries).
Because loggers can be turned on and off in various ways, it’s important to use a logger with a name that’s related to the code that’s using it (logger names typically come from class and package names). There are three ways of getting a Logger instance:
- Calling Logger.getInstance(Class) , the most common.
- From Kotlin, calling com.intellij.openapi.diagnostic.LoggerKt#logger() , e.g. val LOG = logger<FeatureUsageSettingsEventScheduler>() .
- From Kotlin, calling com.intellij.openapi.diagnostic.LoggerKt#logger(KProperty) to be used in top-level functions.
If you are only logging in exceptional situations, consider constructing the Logger instance only once you need it, e.g. when dealing with an exception. The logging infrastructure has a cost, so this way you don’t pay for what you don’t need. If you log during normal IDE operation (on INFO or DEBUG level), store the logger in a static final field, so it’s not recreated every time it’s used. See go/adtstyle for more details.
Make sure to provide enough information and a Throwable instance when available. The idea.log file is often the only piece of information we get from users and it makes life a lot easier if it can be used to fix a problem that cannot be reproduced locally.
Pick the right level for every message. Scanning attached log files for errors and warnings is the first step in triaging a bug, so try not to spam these levels. Use the ERROR log level only in the case of genuinely unexpected errors. Error logs grab user’s attention since they flash a red icon in the status bar. In addition, the number of times these happen is tracked via metrics as a proxy for Studio quality. Typically, scenarios that you can recover from should not be errors. Exceptions logged as errors can be found in our exceptions dashboard.
Remember that formatting the strings and writing to the log file takes time, so consider using DEBUG level for any additional information (and see the section below on how to get that information back).