I have a library, say LIB, which exposes the quite a few APIs and classes for use by application developers.
If there are more than one applications that use LIB on
With the library project, you have a static inclusion of the classes and resources from the library project. Nothing will be running that doesn't need to be.
That can increase the size of your app, but techniques such as ProGuard can remove unused classes from your final .apk.
If you want your library to be running independently of other apps, then it is indeed a service and you should consider what the lifecycle should be (e.g. started by the app, started at boot, etc.).
If your lib contains activities to be run, the Android OS already handles this - the other app just creates an intent and calls out your activity. This is how Android works - apps can share data and workflow between each other seamlessly using intents.
If there are services, it's the same thing - the calling app either interacts with a running service or triggers a service to start.
Library projects handle a lot of issues for most developers, but if you have a really large shared code package you'll want to install as a separate app.
For example, Google Maps is a separate app, but other apps can trigger an intent to load an activity from that app. The same with messaging and other activities that can be handled by different apps.