Bouncy Castle started when two colleagues were tired of having to re-invent a set of cryptography libraries each time they changed jobs working in server-side Java SE.
The intent is to use the low-level API in memory constrained devices (JavaME) or when easy access to the JCE libraries is not possible (such as distribution in an applet).
As the light-weight API is just Java code, the Java virtual machine (JVM) does not impose any restrictions on the operation of the code, and at early times of the Bouncy Castle history it was the only way to develop strong cryptography that was not crippled by the Jurisdiction Policy files that prevented JCE providers from performing "strong" encryption.
In the case of the JCE level of the Java API, the provider is still largely a drop-in replacement for the regular release.
[9] Due to class name conflicts, this prevents Android applications from including and using the official release of Bouncy Castle as-is.
A third-party project called Spongy Castle distributes a renamed version of the library to work around this issue.
It turned out due to Android's DEX file processing that for FIPS purposes the provider needs to be installed on the device separate from the application.