Search Issue Tracker
Won't Fix
Votes
0
Found in [Package]
1.0.0
Issue ID
1180272
Regression
No
[Android Logcat] The editor window doesn't refresh properly when switching between build targets
The Android Logcat window doesn't seem to recognise when you switch between build targets properly.
For example, if you start with Standalone selected, the logcat window will display the "You need to set the build target to Android" message. If you then switch to Android, the window will recognise it and switch appropriately. If you then switch back to standalone, the window will not recognise the change and you'll be able to continue using the window even though you are on the wrong build target.
1. Open Unity
2. Open the attached Project
3. Make sure the build target is set to desktop standalone
4. Open the Android Logcat window via Window > Analysis > Android Logcat
5. Switch the build target to Android
6. Switch to the logcat window and verify that it detects the build target change
7. Switch the build target back to Standalone
8. Inspect the logcat window
Expected Result:
The window recognises that the build target has changed to something other than Android and displays an appropriate message to the user.
Actual Result:
The window continues to behave like the build target is still set to Android.
Tested on Windows.
Occurs on package version 1.0.0
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
- “ArgumentException: Invalid double parameter.” error is thrown when Infinity is typed into the Fixed Timestep field
- GameObject becomes gray when using HDRP and STP together on macOS
Resolution Note:
The logcat team feels this is not specifically a logcat issue, and wants a new case entered that does not use Logcat to reproduce it