· Fuzal
Firebase Pulse: Private Feature Requests with Verified Email Delivery
A native Android request form with saved drafts, retry-safe delivery, private routing, and a confirmed app-to-inbox test.
Firebase Pulse now has a private way to request improvements from inside the Android app. The new form asks for a feature title, an explanation of the idea, and an optional reply email. It sends the request through a server-side email service without placing the team's destination address or mail credentials in the app.
The backend is deployed, and a controlled request from the installed Android build reached the intended inbox. This article describes Firebase Pulse 1.2.2 (14), verified on a connected phone. It does not announce a Google Play rollout of this build.
A short form with clear delivery states
The header includes a Request a feature action. Describe what you would like to do and how it would help. A reply email is optional; Google account credentials, Firebase project contents, and device files are not attached.
The form distinguishes sending, confirmed acceptance, temporary unavailability, rate limiting, and errors. It disables duplicate send actions while a request is in progress. If a submission fails, the draft stays available. Rotation and closing and reopening the form retain the draft during the activity session; saved state also preserves it when Android restores that session.
Retries keep the same request identity
Each submission has a request ID. Retrying an unchanged idea reuses that ID, including after saved-state restoration. Editing the draft starts a new submission identity.
The backend records a short-lived payload digest and delivery outcome. If a previously accepted request is retried within the 24-hour metadata window, the service returns its existing acknowledgement instead of sending another email. Reusing the same ID with different content is rejected as a conflict.
This reduces duplicate delivery without claiming exactly-once email. A broken connection can leave SMTP acceptance uncertain. The service records that uncertainty and avoids blindly resending the same request inside the retry window.
Provider acceptance and inbox arrival are different checks
The app clears the draft only after an explicit success acknowledgement. Its confirmation says the request was accepted for email delivery. That wording matters: acceptance by the email provider is not proof that a message has reached an inbox.
For the live check, the installed app submitted a clearly labeled test idea. The provider accepted it, the app showed success and cleared the form, and the recipient then confirmed arrival. No private inbox address appears in the public client or this article.
One maintained backend, one enabled app
The delivery code is organized as a reusable service, while Firebase Pulse keeps its existing app-specific endpoint. That endpoint binds requests to Firebase Pulse and resolves branding and mail routing from private server configuration.
Only Firebase Pulse is enabled in this service today. Other apps have not been migrated. Their existing request storage, authentication, administration, and delivery workflows remain separate.
Short filesystem locks protect metadata updates and are released before SMTP communication. Network operations have bounded timeouts, and scheduled cleanup removes expired metadata in bounded batches. Operational records do not store the submitted idea or reply address; the email itself is processed by Amazon SES and the receiving email provider.
What was verified
- 172 Android unit tests and four controlled USB UI tests passed.
- 27 Python checks, backend behavior and syntax checks, and the project audit passed.
- The actual app was checked in portrait and landscape for discovery, draft recovery, submission, acknowledgement, and clearing after success.
- Public HTTPS responses, unregistered-app isolation, privacy pages, provider acceptance, and inbox arrival were checked separately.
The screenshots use controlled sample data to protect account information. They illustrate the actual app interface; the live email check provides separate evidence for delivery.
Read the feature request privacy details and the Firebase Pulse privacy policy. Please leave passwords, payment information, and sensitive project details out of requests.