Previously the app would crash because Material Dividers inherit from AppCompat and the leanback activity does not. This creates a new layout file with leanback-specific accommodations and code is duplicated in GameDetailsDialog to prevent inflation crashes.
In order to avoid getting stuck making a new dimension file every time a new device is found we take a known value for how large the game card will be, take the screen size, and adjust the grid accordingly.
Sometimes a gecko code would have a title long enough to appear over the checkbox. This is now prevented by marking the text's boundary a 16dp before the start of the checkbox.
When inflating this layout, the layout inflater doesn't expect a View and rather a descendant of ViewGroup. This resulted in a crash which is resolved by using a FrameLayout instead.
This adds PR 10890's new setting to the Android GUI. I'm curious to see
if any Android users might get a performance improvement from it.
Due to how our settings work on Android, I haven't implemented disabling
the checkbox when the graphics backend doesn't support both GS and VS
for point/line expansion, but I don't think that's critical to have.
This is the first step of getting rid of the controller indirection
on Android. (Needing a way for touch controls to provide input
to the emulator core is the reason why the controller indirection
exists to begin with as far as I understand it.)
Compared to the previous solution of using big `synchronized` blocks,
this makes GameFileCacheManager's executor thread release and re-lock
the lock when possible, giving the GUI thread a chance to do a
(comparatively) quick getOrAdd call if it needs to.
This reverts commit fb265b610de08df5509e56beeb3dbff68f7d4396.
The optimization in that commit is safe when the executor thread is
writing and the GUI thread is reading, but I had failed to take into
account that it's unsafe when the GUI thread is writing and the executor
thread is reading. (The native UpdateAdditionalMetadata function loops
through m_cached_files, which is unsafe if another thread is adding
elements to m_cached_files simultaneously.)
Losing out on this optimization isn't too bad, because
719930bb390ed0020b99a7942289d83218e99d69 makes it very unlikely that
both threads will want the lock at the same time.
