# Mobile Lifecycle events

By default, our Android SDK automatically tracks events that represent the lifecycle of your app and your users experiences with it.

By default, we track the following lifecycle events:

*   **Application Installed**: A user installed your app.
*   **Application Updated**: A user updated your app.
*   **Application Opened**: A user opened your app.
*   **Application Foregrounded**: A user switched back to your app.
*   **Application Backgrounded**: A user backgrounded your app or switched to another app.

You might also want to send your own lifecycle events, like `Application Crashed` or `Application Updated`. You can do this using the `track` method. You’ll find a list of properties for these events—both the ones we track automatically and other events you might send yourself—in our [Mobile App Lifecycle Event specification](/integrations/api/cdp/#section/Semantic-events-for-data-out-integrations/mobile-application-lifecycle-event-schemas).

## Lifecycle event examples[](#lifecycle-event-examples)

A lifecycle event is basically a `track` call that the SDK makes automatically for you.

When you look at your source data in Customer.io, you’ll see lifecycle events as `track` calls, where the event `properties` are specific to the name of the event. For example, the `Application Installed` event includes the app `version` and `build` properties.

```json
{
  "userId": "app.installer@example.com",
  "type": "track",
  "event": "Application Installed",
  "properties": {
    "version": "3.2.1", "build": "247"
  }
}
```

## Sending custom lifecycle events[](#sending-custom-lifecycle-events)

You can send your own lifecycle events using the `track` call. However, whenever you send lifecycle events, you should use the *Application EventName* convention that we use for our default lifecycle events.

These [semantic event](/cdp/sources/semantic-events/) names and properties represent [a standard](/cdp/sources/semantic-events/mobile-app/) that we use across Customer.io and our downstream destinations. Adhering to this standard ensures that your events automatically map to the correct event types in Customer.io and any other services you send your data to.

If you opt out of automatic lifecycle events, you can send your own `track` calls for these events. Or, for events we can’t track automatically, you might be able to use a webhook or a callback to collect crash events. For example, you might want to send a `track` call for `Application Crashed` when your app crashes or `Application Updated` when people update your app.

```javascript

CustomerIO.track("Application Crashed", { 
  url: "/page/in/app"
});
```

## Disable lifecycle events[](#disable-lifecycle-events)

We track lifecycle events by default. You can disable this behavior by passing the `trackApplicationLifecycleEvents` option in the `CioConfig` object when you initialize the SDK.

```javascript
import {
  CioLogLevel, CioRegion, CustomerIO, CioConfig
} from 'customerio-reactnative';
  
const config: CioConfig = {
    cdpApiKey: 'cdp_api_key', // Mandatory
    migrationSiteId: 'site_id', // For migration
    region: CioRegion.US,
    trackApplicationLifecycleEvents: false,
    inApp: {
	    siteId: 'site_id', // this removes the use of enableInApp and simplifies in-app configuration
    }
 };
CustomerIO.initialize(config)
```