Yuvi, after today there's a potential I could spend a little time on this, unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend wire up? I did a local version without creating the control using the existing wireup classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is essentially a result count and the ability to scroll /forward/ in the Find list. It's sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and iterated scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway, highlight and scroll forward is probably sufficient if there isn't an easier solution to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS (
https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that for product direction for the apps. There were some performance things that would need to be worked out (see
http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html for a little more context), but my gut says having a tappable finding glass icon (ideally on an embossed icon like most other search engines) to issue the fulltext Wikipedia article search in a fashion somewhat analogous to the web would probably be a way to avoid unnecessary load.
-Adam