* AI libs registering shenanigans on android;
* Fixed resolution aspect + mouse event scaling;
* Proper server init/deinit (through android IPC);
Enabled threaded init in CMT;
* Prevented a deadlock in logger on some devices;
* Fixed frozen intro frame after interrupting the video;
Added android progressbar displaying during initial data loading;
* Hacky fix for choppy animations during heroes movement (should look better now, but it's definitely not a good solution);
* Changes/fixes for new android launcher building process;
* Fixed app hang after getting SDL_QUIT when activity was destroyed;
* Functioanal, configurable advmap swiping support;
* VCMI changes cleanup;
Added few missing VCMI_ANDROID guards on swipe mechanics;
* Removed unneeded sleep in server startup code for android;
* Removed android ioapi hack (fixed in newest ndk);
* Removed unused android's library loading logic;
* Added android's swipe option to settings schema;
* Moved NO_STD_TOSTRING to be defined in global.h instead of build files;
The control flows the following way:
- we receive SDL_KEYDOWN with letter 's' in the adventure map interface
- save dialog opens
- text input receives focus
- text input enables receiving SDL_KeyboardEvent-s which go between DOWN and UP
- the button on keyboard becomes UP (the menu opens very fast)
- text input receives SDL_KeyboardEvent and inserts 's'
- text input receives SDL_KEYUP
So the apparent fix is to open the save dialog on SDL_KEYUP event
If quick combat calculation take a while it's possible to give hero movement command before battle is finished. This will lead to client freeze or crash. To avoid this we must lock adventure interface until battle calculation is finished.
Related movement code for client and AI is plumbed as well. Though at moment code still not finished because it's not teleport hero to the exit tile if he won battle.
CTerrainRect::showPath behaviour changed so it's will only add cross path graphics on embark/disembark and path ending.
We want continuous paths for flying and water walking even when land<-> water transition occur.
This still need investigation, but likely most of external code shouldn't be aware of layers in order to work properly because only LAND and SAIL can be targeted and single tile can't have both of these layers.
