PostHog / PostHog/posthog-android
Feature request: autocapture native logs (gauging interest 👍)
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 90
- Forks
- 49
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 61
Description
Summary
Today, PostHog Logs on Android is manual capture only — you emit logs explicitly via captureLog(...) / the logger API. The SDK does not automatically capture the platform's native log streams.
We're considering adding autocapture for native logs so existing logging "just works" with zero extra instrumentation, and we'd like to gauge how much demand there is before building it.
👍 this issue if you'd use it. Comments about your use case are even more helpful.
Current behavior
Logs are only sent when you call them yourself:
PostHog.logger.info("checkout completed", mapOf("order_id" to "ord_789"))
The following are not captured automatically: android.util.Log (Logcat) and Timber.
Proposed behavior
An opt-in config flag (e.g. logs.autocaptureNativeLogs = true) that hooks into android.util.Log (Logcat) and Timber and forwards them as PostHog log records — respecting the existing severity mapping, beforeSend redaction, rate cap, and resource attributes.
Related issues (other SDKs)
Same proposal is being tracked across our mobile SDKs:
- iOS: PostHog/posthog-ios#673
- Android: PostHog/posthog-android#586 (this issue)
- React Native: PostHog/posthog-js#3956
- Flutter: PostHog/posthog-flutter#449
Posted by the mobile SDK team to gauge interest — not yet scheduled.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
This issue is primarily gauging interest and names no implementation files, tests, or entry points. If scheduled, start by tracing the Android SDK's existing logger and captureLog flow, including beforeSend, rate caps, severity mapping, and resource attributes. Done would require an agreed opt-in design and implementation for android.util.Log and Timber.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile, observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100