The kicker is, I got curious one time and actually had a look at the game's code and was like "...but why". The loot generation function, while it has what I'd call coding no-nos, is still relatively straightforward. Prepare a loot array, determine the enemy, determine whether the enemy is tempted, roll for each item the enemy can drop using Math.random(), append to the loot array, and finally append some nones to the loot array, because the code elsewhere assumes there's at least 4 item slots so gotta make sure that there's always something for it to look at to decide if it should show anything in that slot or not. There's just not much here, meaning there's not much that can break, and most of the sussiest things appear elsewhere in the code in bits that do work (like you can start fights and the enemies are selected properly, and the randomness works for damage).
The only thing that comes to mind is that maybe the built in push function which in flash used to put things at the end of an array puts them in front now in the emulator, so instead of say ending the fight with ['Pink Liquid', 'Pink Liquid', 'none', 'none', 'none', 'none'] the generated loot ends up being ['none', 'none', 'none', 'none', 'Pink Liquid', 'Pink Liquid']. Then the game checks that oops the first 4 things are nones, clearly no loot has been obtained in the fight, and nothing is awarded.
This is the sort of basic assumption reversal that I'd expect many more games to break because in the emulator which worked perfectly fine in actual flash. Maybe they do, and maybe it's why? EDIT: Nope, not it! In fact when using items instead of nones it's still borked, so the problem is elsewhere. EDIT2: It's deeper still, because whatever happens between the end of combat and the loot screen also eats the "no item" text. Ah well, there goes that chance of a quick fix for android. Too bad.