Why CharSequence Doesn’t Define contains(CharSequence) in Java

It is above all a way of insulating data consumers and data providers. You develop your own content provider or extend an existing one if you want to make some of your data public or at least available to other application.

True this can server to control accesses from a security point of view but it also allows you to rework the physical implementation of your data whenever you want. All you need to do is to adapt the back-end of your content provider in that case. The data consumer applications will not have to be rewritten. They will carry on accessing your data through their content resolver unaware of any change in the actual underlying implementation.

Also, Android will instantiate only one instance of your content provider even if the data is accessed by several clients so it will take care of concurrent accesses without you having to care about it.

Finally, I believe it will also handle the drudgery of clean start up and shut down.

Well, most immediate justification for this design decision can be found in method javadocs:

you can cast the return value from this method to Spannable or Editable...

Casts mentioned above are possible only because Spannable and Editable implement CharSequence; String wouldn't allow for that.

For a deeper understanding of the design motivation, take a look at class javadocs:

TextView is a complete text editor...

Above means that TextView object is designed to support frequent changes of its content.

If getText would return immutable String, this would mean a high chance of creating multiple objects while working with TextView. This in turn would go against general approach preferred in Android and outlined in Avoid Creating Unnecessary Objects guidelines:

Object creation is never free. A generational garbage collector with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory.

As you allocate more objects in your app, you will force a periodic garbage collection, creating little "hiccups" in the user experience. The concurrent garbage collector introduced in Android 2.3 helps, but unnecessary work should always be avoided.

Thus, you should avoid creating object instances you don't need to...

For the sake of completeness, it is worth noting that reasoning in above guidance implicitly involves mobile applications specifics.

In particular, one can imagine desktop or server platforms having more sophisticated garbage collection, allowing developers to design immutable objects at their discretion, without worrying much about performance implications.

At mobile platforms, API designers have to take into account resource limitations of mobile devices (memory, processor, power consumption etc) that can block implementation of theoretically better approaches.