---
title: "Health Connect Metadata: recordingMethod, Device and the fields Health Connect fills in"
canonical: "https://aifitnessapi.com/health-connect-api/metadata-recording-method"
cluster: "Health Connect API"
primary_query: "Health Connect Metadata recordingMethod"
last_reviewed: "2026-10-04"
description: "Health Connect Metadata per Google's docs: the four RECORDING_METHOD constants, the factory functions, Device types, DataOrigin and lastModifiedTime."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Health Connect Metadata: recordingMethod, Device and the fields Health Connect fills in\", AIFitnessAPI, https://aifitnessapi.com/health-connect-api/metadata-recording-method"
---

# Health Connect Metadata: recordingMethod, Device and the fields Health Connect fills in

> Every Health Connect record needs a Metadata object, and since Jetpack 1.1.0-alpha12 you build it with a factory function, such as Metadata.activelyRecorded(), autoRecorded(), manualEntry() or unknownRecordingMethod(), instead of a constructor. The factory sets one of four RECORDING_METHOD constants, and the actively and automatically recorded ones require a Device with a type such as Device.TYPE_WATCH. Health Connect itself fills in id, dataOrigin and lastModifiedTime at insertion and ignores any value you assign to them beforehand.

- Canonical: https://aifitnessapi.com/health-connect-api/metadata-recording-method
- Last reviewed: 2026-10-04
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Health Connect Metadata: recordingMethod, Device and the fields Health Connect fills in", AIFitnessAPI, https://aifitnessapi.com/health-connect-api/metadata-recording-method

---

Every Health Connect record carries a `Metadata` object, and since the Jetpack SDK's 1.1.0-alpha12 release you can no longer write a record without choosing one deliberately. This page covers how `Metadata` is built, the four recording methods, the `Device` it may require, and the fields Health Connect fills in for you. Google's own warning on its metadata guide sets the stakes: "Updating Jetpack versions without implementing these changes will break your Health Connect integration."

## What Metadata is

The reference calls it the "Set of shared metadata fields for `Record`", added in 1.1.0. Google's metadata guide states the rule that changed: "You must specify metadata details whenever a `Record()` type object is instantiated." and "Metadata can no longer be directly instantiated, so use one of the factory methods to get a new instance of metadata. The factory methods verify that device information is provided when a device or sensor was used to record the data. For manually entered data, providing device information remains optional."

## The four recording methods

| Constant | Value | Google's guide | Jetpack reference |
| --- | --- | --- | --- |
| `RECORDING_METHOD_UNKNOWN` | 0 | "The recording method cannot be verified." | "Unknown recording method." |
| `RECORDING_METHOD_ACTIVELY_RECORDED` | 1 | "The user initiated the start or end of the recording session on a device." | "For data actively recorded by the user." Its example: "An exercise session actively recorded by the user using a phone or a watch device." |
| `RECORDING_METHOD_AUTOMATICALLY_RECORDED` | 2 | "A device or sensor recorded the data." | "For data recorded passively by a device without user explicitly initiating the recording, or whenever it cannot be determined." Its example: "Steps data recorded by a watch or phone without the user starting a session." |
| `RECORDING_METHOD_MANUAL_ENTRY` | 3 | "The user entered the data." | "For data manually entered by the user." Its example: "Nutrition or weight data entered by the user." |

For both actively and automatically recorded data the reference adds: "`device` must be specified when using this recording method." The `unknownRecordingMethod` factories carry a note that they are only for a recording method that is genuinely unknown, so do not use them as a shortcut to avoid supplying a device.

You never set `recordingMethod` directly. It is filled in by the factory you call, and readers see it as `metadata.recordingMethod`, an `Int` that the reference says "should be one of" the four constants.

## The factory functions

Each recording method has three factories. Signatures here are from the Jetpack reference, all listed as added in 1.1.0:

| Recording method | Plain | With your own ID | Updating by Health Connect ID |
| --- | --- | --- | --- |
| Actively recorded | `activelyRecorded(device: Device)` | `activelyRecorded(device, clientRecordId, clientRecordVersion = 0)` | `activelyRecordedWithId(id: String, device: Device)` |
| Automatically recorded | `autoRecorded(device: Device)` | `autoRecorded(device, clientRecordId, clientRecordVersion = 0)` | `autoRecordedWithId(id: String, device: Device)` |
| Manual entry | `manualEntry(device: Device? = null)` | `manualEntry(clientRecordId, clientRecordVersion = 0, device = null)` | `manualEntryWithId(id: String, device: Device? = null)` |
| Unknown | `unknownRecordingMethod(device: Device? = null)` | `unknownRecordingMethod(clientRecordId, clientRecordVersion = 0, device = null)` | `unknownRecordingMethodWithId(id: String, device: Device? = null)` |

Each `...WithId` variant is documented as "Creates Metadata to update a record with an existing UUID", and the reference says: "Use this only when there's no client ID or version associated with the record." The client-ID variants are how you upsert from your own datastore; the rules for `clientRecordId` and `clientRecordVersion` are on the [insertRecords and clientRecordId page](/health-connect-api/insertrecords-clientrecordid-upsert).

```kotlin
val watch = Device(
    type = Device.TYPE_WATCH,
    manufacturer = "Google",
    model = "Pixel Watch"
)

val steps = StepsRecord(
    startTime = start,
    startZoneOffset = null,
    endTime = end,
    endZoneOffset = null,
    count = 120,
    metadata = Metadata.autoRecorded(
        device = watch,
        clientRecordId = "steps-2026-10-04T09",
        clientRecordVersion = 1L
    )
)
healthConnectClient.insertRecords(listOf(steps))
```

Use named arguments for the client-ID factories. Google's metadata guide lists the actively and automatically recorded variants as `(clientRecordId, clientRecordVersion = 0, device)`, while the reference lists `(device, clientRecordId, clientRecordVersion = 0)`; named arguments compile against either order.

## Device and device types

`Device` is "A physical device (such as phone, watch, scale, or chest strap) which captured associated health data point." Its constructor is `Device(type: Int, manufacturer: String? = null, model: String? = null)`. Google's guide: "You must specify a device type for all automatically and actively recorded data", and "If known, provide the `manufacturer` and `model` of the device in addition to device type. Doing so helps with attribution in reader applications."

| Base types | Value | Extended types | Value |
| --- | --- | --- | --- |
| `TYPE_UNKNOWN` | 0 | `TYPE_CONSUMER_MEDICAL_DEVICE` | 9 |
| `TYPE_WATCH` | 1 | `TYPE_GLASSES` | 10 |
| `TYPE_PHONE` | 2 | `TYPE_HEARABLE` | 11 |
| `TYPE_SCALE` | 3 | `TYPE_FITNESS_MACHINE` | 12 |
| `TYPE_RING` | 4 | `TYPE_FITNESS_EQUIPMENT` | 13 |
| `TYPE_HEAD_MOUNTED` | 5 | `TYPE_PORTABLE_COMPUTER` | 14 |
| `TYPE_FITNESS_BAND` | 6 | `TYPE_METER` | 15 |
| `TYPE_CHEST_STRAP` | 7 | | |
| `TYPE_SMART_DISPLAY` | 8 | | |

Each extended type "Requires `androidx.health.connect.client.HealthConnectFeatures.FEATURE_EXTENDED_DEVICE_TYPES`. If the feature is not available, this device type will be treated as `TYPE_UNKNOWN`." That flag was added in 1.2.0-alpha06; how to check it is on the [getFeatureStatus page](/health-connect-api/getfeaturestatus-feature-availability).

Google's metadata guide also describes a Unique Device Identifier (UDI) for medical devices on "Android 17 (API level 37.1) or U extension 23 or later", written with the `WRITE_DEVICE_UDI` permission, which it calls "a normal permission" granted at install time. It says to populate only the device-identifier portion and "Don't include any production identifier attributes (such as serial numbers or batch numbers)." The Jetpack `Device` reference fetched for this page lists no `udi` parameter in its constructor, so check the SDK version you compile against before relying on it.

## The fields Health Connect fills in

| Property | Type | Reference |
| --- | --- | --- |
| `id` | `String` | "Unique identifier of this data, assigned by Health Connect at insertion time." |
| `dataOrigin` | `DataOrigin` | "Where the data comes from, such as application information originally generated this data." |
| `lastModifiedTime` | `Instant` | "Automatically populated to when data was last modified (or originally created)." |

For all three, the reference says that before insertion the field holds a sentinel value and "any assigned value will be ignored". `DataOrigin` itself "Specifies the original source of any `Record`: application that inserted it and device on which the data was generated", and its `packageName` is "auto-populated by Health Platform at insertion time of the client package name."

These fields are what sync and attribution are built on. Google's sync guide says to use "the `id` and the `lastModifiedTime` from its `metadata` to upsert the record" when processing an `UpsertionChange`, and its UI guide says to show where data came from using "the `packageName` property of the `DataOrigin` class". Filtering reads by app uses the same type, as `dataOriginFilter = setOf(DataOrigin("com.example.app"))`.

## On-device steps changed origin in June 2026

Google's read guide warns that "Starting with the Health Connect update in June 2026, on-device steps are attributed to a device-specific Synthetic Package Name (SPN) instead of the generic `"android"` package name." Steps recorded before then keep `android`. Because SPNs are "scoped and device-specific, you must not hardcode SPN values"; Google points to `getCurrentDeviceDataSource()`, which it says "is not yet available in the Health Connect Jetpack library", so its example calls the framework `HealthConnectManager` instead. If your app filters steps by `DataOrigin`, include both `android` and the current SPN. An aggregate that does not filter by origin needs no change.

## Pitfalls

- **Upgrading the library breaks record constructors.** Google: "If `metadata` is not included in your `Record` constructor, you might see a Constructor internal error." Every record you build needs a factory-made `Metadata`.
- **Using `TYPE_UNKNOWN` to dodge the device rule.** The factories accept it, but Google's guide asks for the real type plus manufacturer and model where known, because readers use them for attribution.
- **Writing extended types without the feature check.** On Health Connect builds without `FEATURE_EXTENDED_DEVICE_TYPES` the value is stored as `TYPE_UNKNOWN`. Google's own upgrade checklist spells the flag `FEATURE_EXTENTED_DEVICE_TYPES`; the constant is `FEATURE_EXTENDED_DEVICE_TYPES`.
- **Setting `id` or `dataOrigin` yourself.** Ignored before insertion. To update a record by its Health Connect ID, use a `...WithId` factory.
- **Hardcoding the step origin.** Filtering only `DataOrigin("android")` misses on-device steps written after the June 2026 change.
- **Tests that need populated metadata.** The `connect-testing` artifact's `Metadata.populatedWithTestValues(id, dataOrigin, lastModifiedTime)` fills in the system fields; [Health Connect test data](/test/health-connect-test-data) covers the test setup.

## FAQ

### Why does my Health Connect record constructor fail after upgrading to connect-client 1.1.0-alpha12?

Because Metadata became mandatory and can no longer be instantiated directly. Google's metadata guide says you must specify metadata whenever a record is instantiated, using a factory such as Metadata.manualEntry() or Metadata.activelyRecorded(device), and warns that a record built without metadata can produce a Constructor internal error. Device-recorded data also needs a device type.

[Permalink](https://aifitnessapi.com/health-connect-api/metadata-recording-method#faq-1)

### What is the difference between RECORDING_METHOD_ACTIVELY_RECORDED and RECORDING_METHOD_AUTOMATICALLY_RECORDED?

Who started the recording. Google's reference describes actively recorded data as recorded by the user, for example an exercise session the user starts on a phone or watch, and automatically recorded data as recorded passively by a device without the user explicitly starting it, for example background step counting. Both require a Device in the metadata.

[Permalink](https://aifitnessapi.com/health-connect-api/metadata-recording-method#faq-2)

### Which Health Connect Device types need the extended device types feature?

Seven of them: TYPE_CONSUMER_MEDICAL_DEVICE, TYPE_GLASSES, TYPE_HEARABLE, TYPE_FITNESS_MACHINE, TYPE_FITNESS_EQUIPMENT, TYPE_PORTABLE_COMPUTER and TYPE_METER. Google's reference says each requires HealthConnectFeatures.FEATURE_EXTENDED_DEVICE_TYPES, and that on devices without the feature these types are treated as TYPE_UNKNOWN.

[Permalink](https://aifitnessapi.com/health-connect-api/metadata-recording-method#faq-3)

### Can I set the id or dataOrigin of a Health Connect record before inserting it?

No. Google's reference says id, dataOrigin and lastModifiedTime hold sentinel values before insertion and that any value you assign is ignored. Health Connect assigns the id, records the inserting app's package name as the data origin and sets the last-modified time itself. To update an existing record by its Health Connect id, use a WithId factory such as manualEntryWithId.

[Permalink](https://aifitnessapi.com/health-connect-api/metadata-recording-method#faq-4)