Android components are separate system entry points with distinct lifecycles

Android exposes four application components, and each one is a separate entry
point the system can invoke. Activities present a single screen, Services run
background work without UI, receivers answer system announcements, and
providers share structured data across apps.

Every component carries its own lifecycle, so creation and destruction rules
never transfer between kinds. Application fundamentals
describe started versus bound Services and cross-app Activity invocation as
distinct mechanisms.

I would choose the component by trigger and lifetime first, then write the UI
or worker inside it. Modern guidance favors a single Activity hosting many
destinations, per the architecture guide.

Since Shared mobile code still needs platform boundaries, these entry
points belong in platform adapters rather than portable logic. And because
Mobile permissions are revocable feature dependencies, each entry point
must recheck protected access on use.

Design the boundary the system sees, then share only the rules behind it.