The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Usually, Android devices are mobile. Usually, servers are not mobile.
However, occasionally, you may have a valid reason to want to have your Android app expose some sort of open TCP/IP port to other apps, the user, or (eek!) the Internet at large. The “eek!” is because allowing foreign devices access to stuff inside a user’s device is fraught with security issues, as usually Android devices lack configurable firewalls and the other protection measures associated with production-grade servers.
In this chapter, we will explore some reasons for having such a TCP daemon as part of your app, focusing on the most common scenario: serving Web content from your app. We will then examine more closely one embeddable Web server implementation and how you can use it — carefully – in your Android apps.
In addition to having read the core chapters of this book, you should have some familiarity with setting up a Web server and a Web application. This chapter is not a primer on these topics, but instead focuses on how to do them in the context of an Android app.
Some people reading this chapter might wonder what role a Web server would ever have being in an Android app. Sure, we talk to Web servers all the time, particularly those hosting Web services. But publishing a Web server is uncommon, to say the least.
However, “uncommon” does not mean “completely ridiculous”. Even though there are security concerns with having Web servers embedded in Android apps, there are plenty of use cases as well.
One way to mitigate the security issues is to use the Web server
only in constrained situations. One common situation is “development”:
if the Web server is only used in, say,
debug builds, we do not have
to worry about security concerns affecting ordinary users. This reduces
the potential audience of those who might be affected by some attacker.
One popular example of this is Facebook’s Stetho, which extends Chrome DevTools to be able to examine Android apps, including:
Stetho accomplishes this through an embedded HTTP daemon that Chrome DevTools communicates with.
This book’s chapter on custom in-app diagnostic tools will examine how you can use the techniques outlined in this chapter to build your own Stetho-style diagnostics.
Other tools, like Opersys’ Binder Explorer, serve up Web content from a device, but are standalone tools, not designed to be embedded in an app.
Running Web servers on end-user devices is a bit frightening. Not only do normal Android security measures, like permissions, play much of a role, but we lack most of the security infrastructure seen with traditional Web servers.
The counterbalance is that mobile devices rarely have public IP addresses. This limits the scope of potential attackers to those on the same network. Later in this chapter, we will explore various ways of securing these sorts of servers from this limited attacker audience.
Putting the security issues aside for a moment, there is one main reason why one might want to run a Web server on a mobile device: you want other things, outside the device, to talk to your app. There are many possible use cases here, such as:
The preview of this section will not appear here for a while, due to a time machine mishap.
The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).
The preview of this section is [REDACTED].
The preview of this section is in an invisible, microscopic font.
The preview of this section was stepped on by Godzilla.
The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.