Currently the only browser that can be automated in our Android emulators is the stock browser (i.e Browser). The Android stock browser is an Android flavor of ‘chromium’ which presumably implies that its behavior is closer to that of Google Chrome.
CORDOVA is a very famous system that enables you to develop webview-based apps for all platforms in a short time. Appium does not explicitly say that Cordova is supported, even though they do it implicitly as some examples using apps built with Cordova are provided on Appium’s website. So the answer is that Cordova should not be a problem. Why am I being so shy about it? Because anything can happen and it actually happened to me!
Cordova and Appium are two different projects that are growing up separately and independently, of course, a mutual acknowledgment is present, but both teams do not really talk to each other when pushing features. So problems can occur (I am currently dealing with a problem concerning Cordova’s new version which is causing my tests to fail).
Depending on what you have to debug, you will probably need to go deeper in your debugging experience, however, there are some key points were setting a breakpoint is always worth: the proxy component is worth a mention. In appium/lib/server/proxy.js you can set a breakpoint in function doProxy(req, res), that will be hit every time commands are sent to platform-specific components to be translated into automation commands.
In order to make things better, as a developer, what you can do is adding testability layers to your app. The logic behind this approach is simply having some test-related objects in your app which are activated only when your tests run. Enable your testability layers when testing in order to make data exchange easy.
Appium, actually the WebDriver specification, is not made for exchanging data with your app, it is made to automate it. For this reason, you will probably be surprised in finding data exchange not so easy. Actually it is not impossible to exchange data with your app, however, it will require you to build more layers of testability.
Here is one piece of advice. Since your tests will mostly consist of automation tasks (if this condition is not met, you might want to reconsider using Appium), make interactions reusable!
Do not write the same sub-scenarios twice in your tests, make a diagram of what your scenarios are and split them into sub-activities; you will get a graph where some nodes are reachable from more than one node. So make those tasks parametric and call them in your tests! This will make your test writing experience better even when you need to migrate from existing tests (hopefully you already did this activity for your existing suites).
On the other hand, emulators/simulators will never disconnect from Appium. They also offer nice options like the ability to choose the orientation or other hardware-related configurations. However, your tests will run much slower (sadly, my tests ran 3 times slower) and do expect some crazy behavior from the Android emulator which sometimes shuts down unexpectedly. Another problem is that emulators tend to allocate a lot of memory.
Appium is available on GITHUB and there you can find all you need. The Appium team is responsible for developing many different subsystems revolving around Appium (like APIs for different languages), thus I can tell you that this product is alive and very active. The team is also pretty well responsive and once you open an issue you will find a reply after no more than 36 hours (this ETA comes by my personal experience). The community around Appium is also pretty large and growing every month.
Hand down my chin starting thinking and mumbling. If I had to provide one single thing you should be aware of about Appium before starting using it, it would surely be multiple session handling. Since Appium is a server, it serves HTTP requests; you might have two different computers running a test each against the same Appium server: what happens? As for now, Appium does not support this scenario and the second test will be aborted.
This is a considerable limitation because no queuing system comes with Appium. If you need to support multiple sessions, you will need to implement this feature by yourself.
This is an implied question in this question. The answer is No (in general). As I said before Appium is not suitable for all types of tests you might want to write (this depends on the functionalities you need to cover). There are some scenarios that can be difficult to test and some of them are so platformed specific that you will need to write some suites just for Android or iOS for example.
Remember that you can always get to do something no matter how hard it is, so you can test all your difficult scenarios using Appium, but always keep in mind one question: is it worth the time and the pain? Having Appium testing some scenarios leaving a few tests to other approaches is fine too! The world is not black and white!