I want to figure out why in an old app when run on a modern Android phone (Android 14), the old options menu panel only opens once and then remains stubbornly closed. Luckily the app was built without obfuscation, so it wasn't that difficult to get started debugging.
Along the way, I also had to start debugging into the Android framework code. For the more "public" parts of the framework (e.g. android.app.Activity), that is no problem – Android Studio just opens the corresponding source file and everything works as usual (as long as I debug on an emulator, so the line numbers match up exactly).
However some parts of the framework sources are treated in a seemingly more secretive manner, and that's where the problems start:
- Using "Step into" starts behaving wonky, and often just leads to hangs, although that can be circumvented by using "Force step into" instead
- Equally annoying, Android Studio no longer automatically opens the corresponding source file, and, even if I open it manually, no longer highlights the current execution point. Thankfully at least setting method breakpoints still works, though.
Yellow background with black text are the framework classes where debugging works normally, whereas yellow blackground with a grey text are the classes that don't work automatically (like e.g. com.android.internal.policy.PhoneWindow):
I've tried poking around inside Android Studio's settings, but none of the options for the debugger (especially those under 'Stepping') seem relevant. There is an 'Do not step into the classes' settings, but that only includes mostly Java-internal classes, but not the Android framework.
Is there some way of forcing Android Studio to treat those internal framework classes more normally, too? As a workaround, I can just use "Force Step Into" when necessary and manually follow execution progress along, but of course this still is a bit annoying.