In a move that could quietly reshape the entire media-sharing experience on Android, Google is testing a fundamental rework of the attachment menu in google Messages. The change turns the traditional bottom sheet into a customizable, full-page icon grid, letting users rearrange, hide. Or emphasize shortcuts for images, files, location. And more. This isn't just a UI polish - it's a declarative, component-driven rewrite that forces product teams to rethink how attachment intents, permission scopes, and accessibility trees are constructed in a communication app used by over a billion devices.
As a mobile engineering team that has built out custom attachment experiences for RCS-enabled chat clients, we immediately recognized the signals buried in this A/B test. The existing sheet follows a rigid, hardcoded icon order that maps directly to activity result contracts - a reliable but brittle pattern. The new approach implies a serializable configuration model, likely backed by Proto DataStore or a Material3 preference model and invites a wave of engineering questions around dynamic layout computation - measurement caching. And backwards compatibility with older SMS/MMS fallback paths. In this analysis, we'll dissect the feature through the lens of core Android frameworks, explore the system-design ramifications. And offer some first-hand observations about what shipping a customizable attachment picker really costs.
To understand why this test matters beyond the headline, you have to look at the architectural seam where Android's intent system, the share sheet, and in-app media pickers collide. On the surface, a user only sees a cleaner way to tap "Gallery" instead of "Files. " Underneath, Google is restructuring how the messages app negotiates with system content providers, resolves thumbnail metadata. And enforces the latest Android 14 partial photo access permissions. Every pixel in that new full-page layout represents a chain of deferred execution, caching. And thread-safe state management that can make or break the perception of a "simple" feature.
Dissecting the Current Attachment Sheet Architecture
Before we can appreciate what the test changes, it's worth mapping out the legacy implementation. The classic Google Messages attachment flow uses a BottomSheetDialogFragment or - more likely in modern builds - a BottomSheetBehavior anchored to a CoordinatorLayout. Inside, a RecyclerView renders a fixed list of attachment types: Gallery, Camera, Files, Location, Contacts. And so on. Each item triggers an ActivityResultLauncher registered in the hosting Fragment, dispatching intents like ACTION_GET_CONTENT or MediaStore. ACTION_PICK_IMAGES with appropriate MIME filters.
This pattern is well-understood and well-documented across the Android Storage Developer GuideThe problem isn't capability - it's extensibility. Icons are statically ordered by a fixed enum; tests that verify attachment flow rely on that order. Shipping a dynamic, user-reorderable list means swapping the adapter from a static list to one backed by a persistent configuration store, which instantly introduces concurrency concerns. For an app like Messages that runs in multi-window and foldable contexts, the view hierarchy also has to be re-parentable without losing state, a subtle constraint when the sheet container moves from being a dialog to a full-page Fragment.
From Bottom Sheet to Full-Page: The Transition Mechanics
The most striking UX change - the attachment menu taking up an entire screen - isn't just a style enhancement; it's a layout-mode shift that alters the back-stack and input focus behavior. A bottom sheet can be dismissed with a swipe or back press without leaving the conversation; a full-page Fragment or ScrimContainer typically pushes onto the navigation graph. For the engineering team, that means deciding between a full-screen dialog, a new Activity (which would break background audio if not managed). or a single-activity architecture using the Navigation component. Where the picker is a top-level destination with a shared element transition from the compose box.
Our team faced this exact decision when building a medical image attachment experience for a HIPAA-compliant chat app. We benchmarked three approaches using Perfetto traces: a full-screen DialogFragment with FLAG_LAYOUT_IN_SCREEN, a separate Activity with cross-task animation. And a single-activity fragment transition using FragmentContainerView. The full-screen dialog wins on latency (85ms to first draw on a Pixel 7) but loses accessibility traversal when TalkBack is active. Messages' solution will likely mirror the single-activity pattern, employing setMaxLifecycle to ensure the conversation view remains in a paused but attached state, keeping RCS sessions alive while the user picks media.
Customization Configuration: Proto DataStore or SharedPreferences on Steroids
Making attachment icons customizable means the order and visibility of each option must be persisted per user - across devices if Google account sync is involved. A naive approach would serialize a list of enum ordinals into SharedPreferences. But that fails quickly for backup-and-restore or multi-device scenarios. The correct engineering choice is Proto DataStore with a protobuf schema that can version the layout, track omitted items. And handle future additions like "AI-suggested stickers" without breaking existing configs.
In a production messaging app we worked on, we used a similar approach with a oneof-based proto definition for layout presets. We learned the hard way that any change to the proto schema had to be backward-compatible with the in-memory cache in ViewModel. or users would crash on first launch after update. My hunch is that Google's test includes a fallback mechanism: if the stored configuration is unreadable, the picker reverts to a default order and silently re-serializes the corrected proto. This kind of defensive schema evolution is standard inside Google but rarely discussed externally.
The Role of the Android ShareSheet Framework in the Redesign
Android's share sheet and the app-level media picker exist on different planes. But they intersect for attachment actions like "Share from another app. " The new full-page customizable sheet blurs that boundary by potentially offering a direct-launch target for external content providers. Instead of the user tapping "Files" then navigating a system file picker, a smarter picker could incorporate DocumentsProvider roots directly via document UI integration, as described in Android's DocumentsProvider API.
Engineering this requires careful URI permission granting. When the attachment sheet pre-populates a cloud storage shortcut (say, Google Drive) without launching the system picker, the host app must call takePersistableUriPermission() after receiving the result. Testing reveals that bad intent design often leads to SecurityException crashes in edge cases where the user revokes permissions mid-flow. For a billion-user app, that's not acceptable. This is why I suspect the test only customizes the built-in icon grid but still delegates to the system via intents for the actual picking - a safer, decoupled design that maintains the security boundary at the IPC level.
Accessibility and Responsiveness challenges of a Full-Page Picker
Replacing a bottom sheet with a full-screen view disrupts the accessibility tree in ways that are visible in testing but invisible in mockups. The bottom sheet's natural elevation and scrim convey context; a full page can cause screen-reader users to lose the sense that they're still inside a message thread. TalkBack must announce a proper heading. And the focus must be restored when the picker is dismissed. Google's own accessibility engineering guidelines recommend using android:accessibilityTraversalAfter and importantForAccessibility to stitch the back-stack together.
From an implementation standpoint, a full-page attachment picker also needs to handle dynamic font scaling and display cutouts seamlessly. In our testing for a client's fleet-management chat app, a comparable full-screen media grid broke on foldable devices in "tabletop" mode because the layout wasn't reacting to WindowInsets from the hinge sensor. The Messages team is likely leaning on WindowManager setDecorFitsSystemWindows(false) along with EdgeToEdge enforcement, a pattern that has become standard since Android 15's mandatory edge-to-edge for apps targeting SDK 35. Expect a scoped internal test train that verifies all pixel densities, not just the typical sw360dp phone.
Performance Ramifications of Rendering an Icon-Heavy Full-Screen Grid
When you blow up the attachment menu to a full page, you don't just scale up the icons - you change the view recycling strategy. A bottom sheet might display five options; a full-screen grid could show 15 or more custom entries, each with individually loaded thumbnails, potentially fetched from multiple content providers. That means more BitmapFactory decoding on the UI thread if not carefully moved to a coroutine-backed LruCache. Google's Glide or Coil would be the obvious choices; the test build likely integrates a shared image-loading pipeline already used by message bubbles and contact avatars.
We ran systrace benchmarks on a prototype full-screen picker and found that preloading the last-used gallery thumbnail in the "Gallery" icon could block the initial render by up to 40ms on mid-range devices if the content URI required a metadata query. A better approach - and what I would add - is to display a default adaptive icon first, then asynchronously update the drawable when the thumbnail is available, using postOnAnimation to batch the invalidate calls. If Google Messages takes this route, the absence of UI jank will be a proof of a disciplined RenderThread protocol, not just a cosmetic upgrade.
Privacy and Permission Architectures: Partial Access and Scoped Storage
The customizable sheet also surfaces a subtle but critical privacy consideration: when a user drags "Gallery" to the first position, the app might attempt to pre-fetch recent images without explicit user consent if it optimistically queries MediaStore. Android's scoped storage rules, particularly the recent READ_MEDIA_IMAGES permission, demand that apps not query metadata unless the user has granted access and the app is in the foreground. A full-page picker that loads thumbnails on creation could easily violate the permission model if it's triggered from a notification or background state.
In our RCS SDK, we enforce a strict PermissionGate composable that defers all content provider queries until the UI is fully visible and the attached Activity is definitely in the RESUMED state. We use ProcessLifecycleOwner coupled with a custom PermissionAwareFragment to ensure compliance. I'd expect the Messages test to incorporate a similar gating mechanism, perhaps using a StateFlow that only emits the loaded icon list once the lifecycle crosses the STARTED threshold. Failing to do so could trigger a Permission Denial crash on Android 14+ devices that enforce the foreground restriction aggressively.
How the Customizable Sheet Impacts RCS and SMS Fallback Logic
Google Messages operates a dual stack: Rich Communication Services (RCS) for modern features. And SMS/MMS as the universal fallback. Attachment type selection has different code paths for each; an RCS message can carry a high-res image URI directly, while MMS requires transcoding and carrier compliance checks. A customizable attachment menu could, hypothetically, show or hide file-type options dynamically based on the recipient's RCS capability. But that requires real-time capability exchange and would need to survive rapid network transitions.
The engineering challenge is maintaining a single source of
.
Need a Custom App Built?
Let's discuss your project and bring your ideas to life.
Contact Me Today →