The one big disadvantage I see that happens when running application components in different threads is that the two parts will be in different DVMs. This can make sharing Preference changes, Listeners, Observers, ect, not work as you would expect, you would also have to make sure all DB access is synchronized.
To counter this point if you synchronization correctly and don't need preferences you can use bundles or AIDL to communicate back and forth from the 2 applications. The best bet is AIDL for 2-way continuous communication, but be aware AIDL can be expensive. The other option for communication is a socket... but this goes against the SDK that is provided. A trick I have learned when doing this is to create an API jar file to include in both applications that will handle all communications (by way of intent or AIDL - blackbox approach).
Personally I think application components that are similar should stay in the same DVM and application unless they can run as stand alone then you have to be the judge of that.
Have you though about running the HTTP server as on ongoing foreground service? This would uncouple your design as well as make things easy and lighter.