Posted by Nataraj KR, Android Developer Relations Engineer
The initial launch of the Jetpack Telecom library introduced CallsManager, replacing the legacy ConnectionService API to simplify VoIP integration. CallsManager streamlines call lifecycle management and audio routing while enabling interactions with remote surfaces like smartwatches, Bluetooth devices, and Android Auto. Additionally, it supports call extensions for richer features-such as participant handling, custom icons, call silencing and meeting summary on remote surfaces-all while maintaining backward compatibility down to Android O (API Level 26).
Building on this foundation, Jetpack Telecom v1.1.0 brings native-level visibility and convenience to third-party VoIP apps. This latest release introduces powerful new capabilities, including unified call history, call log exclusion, and native callback functionality, making call management more seamless than ever for users.
Here is a closer look at what's new and how you can implement these features in your applications.
Bridging the Dialer Gap: Unified Call History and Callbacks
Historically, users have had to open individual third-party apps to view their VoIP call history or return a missed call. With the new integrated call logging feature, system dialer apps can now surface call logs directly from third-party VoIP apps.
Even better, users can now initiate a callback to a VoIP contact straight from their native system dialer, streamlining the communication experience.
How it works:
To opt-in to this feature, do the following:
Register for Callbacks: Your VoIP app must register a new system-protected intent: TelecomManager.ACTION_CALL_BACK.
Log the Call: Use TelecomManager.addCall (or related Jetpack APIs) to ensure the system automatically logs the call.
Manage Call IDs: When a call is registered, CallControlScope.getCallId provides a unique UUID. The system dialer uses this exact TelecomManager.EXTRA_UUID when creating the callback intent.
Initiate the Callback: Your application must store and manage the call details associated with this UUID. When the system dialer fires the callback intent with the EXTRA_UUID, your app can seamlessly resolve the ID and initiate the call with the correct details.
Fine-Grained Control: Call Log Exclusion
We recognize that not every VoIP call should be visible in the system's native dialer history. Whether for privacy reasons, ephemeral communication, or app-specific behavior, you need control over what gets surfaced.
To address this, we are introducing Call Log Exclusion. You can now prevent specific calls from being logged into the system call logs by setting the isLogExcluded boolean to true within CallAttributesCompat. By configuring this flag, the call remains completely hidden from the system logs, and the native dialer will not display it.
Important Note on Compatibility
These integrated logging and callback features are available for devices running Android 16.1 (SDK 36.1) and higher. Refer here to compile your app with Android SDK 36.1.
Get Started
We encourage developers to test these integrations and explore how unified call history and callbacks can improve the daily user experience of your VoIP applications.
To help you get started and see these APIs in action, we have put together a sample application demonstrating the new integrations.
Note: Although Jetpack Telecom v1.1.0 APIs are accessible for integration, the system dialer's ability to render native call logs is being introduced in phases, beginning with Google Meet. To safeguard against spam, native dialers utilize secure package allowlists to control VoIP display. For local testing of your callback and logging implementations, we recommend using the open-source Telecom Sample Dialer app as your emulator environment.
Posted by Matthew McCullough, VP, Product Management, Android Developer
Announced today during The Android Show, Android is transitioning from an operating system to an intelligence system, creating more opportunities for engagement with your apps. Through deep integration between hardware and software, Android devices will be able to handle the heavy lifting of anticipating user needs, so your app can focus on delivering that experience at the right moment. As part of this, we are announcing Gemini Intelligence, a suite of new features that bring the best of Gemini to our most advanced Android devices.
Task Automation with Gemini
With Gemini Intelligence, we're expanding Gemini's ability to automate tasks across selected apps on behalf of the user with built-in transparency and control. This creates another avenue for user engagement, driving high-intent traffic to your app without requiring code or major engineering work from you. By allowing Gemini to navigate complex, multi-step tasks, such as ordering a latte from a cafe or building a shopping cart from a grocery list in a notes app, Gemini handles the logistics for users, so you're free to focus on innovation and building great features.
We know there are times when people like to browse, and others when they want to quickly handle a task. Initially launched with selected food and ridesharing partners to build a grocery order or request a ride, this capability is expanding across more verticals and form factors, including foldables, watches, cars, and XR glasses.
Increase Engagement with AppFunctions
For more control over how agents interact with your app, you can use Android AppFunctions. This empowers you to provide specific tools, such as services, data, and actions directly to the OS and agents, paired with natural language descriptions. The system can then discover and execute these tools across form factors, enabling users to trigger your app's functionality through the intelligence system for richer and more customized experiences with task automation. We've started testing these early stage APIs in a private preview with apps like KakaoTalk to enable users to "send messages" or "initiate voice calls" through this new framework. AppFunctions have already enabled local execution of 25 apps' use cases across device manufacturers. You can experiment with the API locally and already register your interest to join the AppFunctions Early Access Program for full integration opportunities.
We're providing multiple integration paths to meet you wherever you are on this intelligence journey, whether it's with an effortless, "no-code change" app automation or using the AppFunctions API, to provide you with more control in an MCP-like fashion.
Enhanced User Experience with Widgets
We're elevating the user experience by expanding widget support to new form factors, starting with cars. This creates new opportunities for you to engage with users on 250M Android Auto compatible vehicles.
Jetpack Glance makes it easy to build high-quality widgets, and it is now getting powerful new capabilities thanks to a new underlying framework called RemoteCompose.
New richer, premium interactions: Built to be deeply adaptive and battery efficient, RemoteCompose allows Glance to deliver richer, more premium interactions. You can soon leverage new capabilities, including snapscroll, expressive buttons, and particle effects to create more engaging widgets.
Built-in Backward Compatibility: These expressive RemoteCompose features are supported out-of-the-box on Android 16 and above. By using Jetpack Glance as your API, you maintain complete backward compatibility. Your widgets will automatically leverage these premium UI features on newer devices while gracefully degrading to support older OS versions.
Furthermore, RemoteCompose is the engine behind Create My Widget, a feature where users can ask Gemini to build fully adaptive custom widgets that can be resized and optimized seamlessly for the user's home screen or Wear OS watch.
Building Adaptively Beyond the Phone
From foldables, tablets, compatible cars, and XR headsets to the new Googlebooks, the canvas for Android apps has expanded across screens and form factors. Here are some of the updates to help you build adaptively:
Jetpack Navigation 3: Our latest Jetpack Navigation 3 offers deeper adaptive support adding Scene decorators to the Scene API. Scene decorators can be used to modify the scene calculated by your app's scene strategy. For example, they can be used to add common UI elements such as top app bars and navigation bars/rails that you'd like to add at the scene, rather than nav entry level. NavDisplay now includes built-in functionality that makes nav entries shared elements so now you can smoothly transition between scenes. Check out our Nav3-recipes for more.
Jetpack Compose: Adopting Compose into your app remains the easiest way to start building adaptive UIs, and we want to ensure that you have the right level of architectural support. We are working on a new set of building blocks in Compose 1.11 for responsive layouts and customization with Grid, Flexbox, MediaQuery and Style. We would love your feedback on them before removing the Experimental flag.
For device-differentiated experiences, take advantage of the latest updates to:
Car App Library: We're streamlining development by expanding the Car App Library, which allows you to "build once" and deliver customized, distraction-optimized media experiences to both Android Auto and Android Automotive OS. We're further enabling richer in-car engagement by expanding support for adaptive video apps, so that videos can played full screen when cars are parked.
Android XR SDK: The Android XR SDK allows you to build deeply differentiated, custom experiences for a growing spectrum of XR devices, including upcoming wired XR glasses (like XREAL's Project Aura), while existing adaptive apps automatically surface in immersive environments without additional developmental effort. You can get ready for display glasses by using Jetpack Compose Glimmer to build glanceable UIs tailored for display glasses, alongside Jetpack Projected APIs to bridge app experiences from the phone to the user's field of view. The developer preview 4 of the Android XR SDK, coming next week, introduces new interactive components like Title Chips and Button Groups that optimize input for glasses touchpads. It streamlines your workflow with the new ProjectedTestRule API to automate testing environments.
A New Age for Your Users on Android
From the shift to an intelligence system to the expansion of new form factors like Googlebooks, Android is creating new ways for people to get more out of their device experiences with developers and app makers at the center of it.
Gemini Intelligence features will roll out in waves as they become ready, starting with the latest Samsung Galaxy and Google Pixel phones this summer. They will also become available across your Android devices including your watch, car, glasses and laptops later this year.
Stay tuned for even more news about app development in this new era at Google I/O next week.
Posted by Ash Nohe and Amrit Sanjeev, Android Developer Relations Engineers
Practicing gratitude may decrease symptoms of depression and anxiety, and improve mental health and life satisfaction1. Consistent gratitude practice may lead to sustained improvements that last months2. The mindfulness app Gratitude encourages consistency through micro daily journaling, affirmations, and vision boards. The app has over 6 million downloads, 150 thousand 5-star ratings, and 100 million journal entries logged.
Developers Divij Gupta and Narendra Aanjna developed widgets for each of their app's core user journeys. Their goal was to meet users in their everyday moments without requiring the overhead of a full app session.
By surfacing interactive journaling prompts, affirmations, vision board images and metrics directly on the user's home screen, the team lowered the barrier to entry for daily reflection and reported a 25% increase in retention for widget users and ~1K weekly journal entries from widgets. This increase in user loyalty translates to tangible health outcomes for the users: consistent habit formations that support long-term mental well-being.
"Widgets helped us make the app more present in users' daily routines by providing quick inspiration, reminders, and reflections directly on the home screen. This increased engagement and made it easier for users to stay consistent with their mindfulness practices." - Divij Gupta
The Challenge: modernize without decreasing retention
While the impact of widgets was clear, Gratitude's original XML-based RemoteViews implementation created technical debt. As the app's design system evolved toward Material 3, the legacy widgets became increasingly difficult to align with the modern UI. Every visual update required manual XML overhead and brittle workarounds, slowing developer velocity.
The Solution Part 1: migrating from XML to Jetpack Glance
To modernize their widgets, the team turned to Jetpack Glance.
They first consulted the Widgets on Android design page and canonical widget layouts to understand best practices for displaying information within a limited amount of space.
Then, they migrated their widget suite to Jetpack Glance. This declarative framework enabled the developers to move from planning to shipping in less than a month, saving about 50% development time, and saw two additional advantages:
Replacing restrictive XML layouts with declarative code made the codebase easier to read, maintain, and reduced developer effort.
Jetpack Glance allowed the team to more easily implement dynamic colors, flexible resizing, and expanded configuration options. These features ensure the widgets harmonize with a user's unique home screen layout.
The following GIF shows two Gratitude widgets and adaptive resizing:
While Glance simplified the UI, the team noted that testing across various OEM launchers was also essential to ensure layout consistency across devices.
The team also implemented Generated Widget Previews so users can see personalized previews. They noted that testing Generated Previews could be slow, as the previews are rate limited to preserve battery. To bypass the rate limiting for testing, use the adb command:
The developers then used in-app widget pinning to increase widget discoverability and widget installs. Asking users to install widgets at a contextually relevant moment within the app helps users find their widgets without needing to go through the system widget picker. The following GIF shows Gratitude's bottom sheet to add widgets from within the app:
The team also refactored widget packages, which changed widget receiver paths and caused widgets to be deleted from users' home screens. Using previously stored user flags to identify widget users, they triggered another requestPinGlanceAppWidget prompt inviting widget users to use the new modernized widgets.
Developer Tip: To maintain widget installs while migrating from RemoteViews to Jetpack Glance, ensure your GlanceAppWidgetReceiver uses the same class name and package as your previous AppWidgetProvider in the Android Manifest. If a new class name or package location is required, follow the Gratitude's lead by using in-app pinning to help users restore their widgets.
The strategy is working, as 10% of total DAU have adopted widgets.
Conclusion
This Gratitude story shows that widgets can be tools for habit formation. By implementing quick actions to self-reflect right from the home screen, the team may have improved user loyalty. Gratitude reduced technical debt and modernized their widgets by adopting Jetpack Glance, and prompted users to add widgets within their app.
"Our experience with Jetpack Glance has been excellent. The Compose-based approach feels much more modern, flexible, and aligned with the way we build the rest of our UI today. It allows us to express widget layouts more naturally, reuse familiar Compose components, and iterate on UI changes much faster. Many of the UI constraints we previously faced with RemoteViews are no longer an issue, which made it easier to build widgets that better match our app's design and experience." - Divij Gupta
Getting Started
To get started with Jetpack Glance and learn about the technologies mentioned in this post, see these guides:
1: Diniz, G., Korkes, L., Tristão, L. S., Pelegrini, R., Bellodi, P. L., & Bernardo, W. M. (2023). The effects of gratitude interventions: a systematic review and meta-analysis. einstein (Sao Paulo)., 21, eRW0371. https://doi.org/10.31744/einstein_journal/2023RW0371
2: Bohlmeijer, E., Kraiss, J., Schotanus-Dijkstra, M., & ten Klooster, P. (2022). Gratitude as mood mediates the effects of a 6-weeks gratitude intervention on mental well-being: post hoc analysis of a randomized controlled trial. Front. Psychol., 12, 799447. https://doi.org/10.3389/fpsyg.2021.799447
Now that 2025 is over, it's time to look back and feel proud of the path we've walked. Last year has been really exciting in terms of contributions to GStreamer and WebKit for the Igalia Multimedia team.
With more than 459 contributions along the year, we've been one of the top contributors to the GStreamer project, in areas like Vulkan Video, GstValidate, VA, GStreamer Editing Services, WebRTC or H.266 support.
Igalia's contributions to the GStreamer project
In Vulkan Video we've worked on the VP9 video decoder, and cooperated with other contributors to push the AV1 decoder as well. There's now an H.264 base class for video encoding that is designed to support general hardware-accelerated processing.
GStreaming Editing Services, the framework to build video editing applications, has gained time remapping support, which now allows to include fast/slow motion effects in the videos. Video transformations (scaling, cropping, rounded corners, etc) are now hardware-accelerated thanks to the addition of new Skia-based GStreamer elements and integration with OpenGL. Buffer pool tuning and pipeline improvements have helped to optimize memory usage and performance, enabling the edition of 4K video at 60 frames per second. Much of this work to improve and ensure quality in GStreamer Editing Services has also brought improvements in the GstValidate testing framework, which will be useful for other parts of GStreamer.
Regarding H.266 (VVC), full playback support (with decoders such as vvdec and avdec_h266, demuxers and muxers for Matroska, MP4 and TS, and parsers for the vvc1 and vvi1 formats) is now available in GStreamer 1.26 thanks to Igalia's work. This allows user applications such as the WebKitGTK web browser to leverage the hardware accelerated decoding provided by VAAPI to play H.266 video using GStreamer.
Igalia has also been one of the top contributors to GStreamer Rust, with 43 contributions. Most of the commits there have been related to Vulkan Video.
Igalia's contributions to the GStreamer Rust project
In addition to GStreamer, the team also has a strong presence in WebKit, where we leverage our GStreamer knowledge to implement many features of the web engine related to multimedia. From the 1739 contributions to the WebKit project done last year by Igalia, the Multimedia team has made 323 of them. Nearly one third of those have been related to generic multimedia playback, and the rest have been on areas such as WebRTC, MediaStream, MSE, WebAudio, a new Quirks system to provide adaptations for specific hardware multimedia platforms at runtime, WebCodecs or MediaRecorder.
Igalia Multimedia Team's contributions to different areas of the WebKit project
We're happy about what we've achieved along the year and look forward to maintaining this success and bringing even more exciting features and contributions in 2026.
Some years ago I had mentioned some command line tools I used to analyze and find useful information on GStreamer logs. I've been using them consistently along all these years, but some weeks ago I thought about unifying them in a single tool that could provide more flexibility in the mid term, and also as an excuse to unrust my Rust knowledge a bit. That's how I wrote Meow, a tool to make cat speak (that is, to provide meaningful information).
The idea is that you can cat a file through meow and apply the filters, like this:
which means "select those lines that contain appsinknewsample (with case insensitive matching), but don't contain V0 nor video (that is, by exclusion, only that contain audio, probably because we've analyzed both and realized that we should focus on audio for our specific problem), highlight the different thread ids, only show those lines with timestamp lower than 21.46 sec, and change strings like Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp to become just AppendPipeline.cpp", to get an output as shown in this terminal screenshot:
Cool, isn't it? After all, I'm convinced that the answer to any GStreamer bug is always hidden in the logs (or will be, as soon as I add "just a couple of log lines more, bro" 0 0
I was playing around with Xlib this summer, and one thing led to another, and here we are with four fresh ports to retro mobile X11 platforms. There is even a Maemo Leste port, but due to some SGX driver woes on the N900, I opted for using XSHM and software rendering, which works well and has the nice, crisp pixel look (on Fremantle, it's using EGL+GLESv2). Even the N8x0 port has very fluid motion by utilizing Xv for blitting software-rendered pixels to the screen. The game is available over at itch.io.
I've mentioned some of my various retronetworking projects in some past blog posts. One of those projects is Osmocom Community TDM over IP (OCTOI). During the past 5 or so months, we have been using a number of GPS-synchronized open source icE1usb interconnected by a new, efficient but strill transparent TDMoIP protocol in order to run a distributed TDM/PDH network. This network is currently only used to provide ISDN services to retronetworking enthusiasts, but other uses like frame relay have also been validated.
So far, the central hub of this OCTOI network has been operating in the basement of my home, behind a consumer-grade DOCSIS cable modem connection. Given that TDMoIP is relatively sensitive to packet loss, this has been sub-optimal.
Luckily some of my old friends at noris.net have agreed to host a new OCTOI hub free of charge in one of their ultra-reliable co-location data centres. I'm already hosting some other machines there for 20+ years, and noris.net is a good fit given that they were - in their early days as an ISP - the driving force in the early 90s behind one of the Linux kernel ISDN stracks called u-isdn. So after many decades, ISDN returns to them in a very different way.
Side note: In case you're curious, a reconstructed partial release history of the u-isdn code can be found on gitea.osmocom.org
But I digress. So today, there was the installation of this new OCTOI hub setup. It has been prepared for several weeks in advance, and the hub contains two circuit boards designed entirely only for this use case. The most difficult challenge was the fact that this data centre has no existing GPS RF distribution, and the roof is ~ 100m of CAT5 cable (no fiber!) away from the roof. So we faced the challenge of passing the 1PPS (1 pulse per second) signal reliably through several steps of lightning/over-voltage protection into the icE1usb whose internal GPS-DO serves as a grandmaster clock for the TDM network.
The equipment deployed in this installation currently contains:
a rather beefy Supermicro 2U server with EPYC 7113P CPU and 4x PCIe, two of which are populated with Digium TE820 cards resulting in a total of 16 E1 ports
an icE1usb with RS422 interface board connected via 100m RS422 to an Ericsson GPS03 receiver. There's two layers of of over-voltage protection on the RS422 (each with gas discharge tubes and TVS) and two stages of over-voltage protection in the coaxial cable between antenna and GPS receiver.
Now that the physical deployment has been made, the next steps will be to migrate all the TDMoIP links from the existing user base over to the new hub. We hope the reliability and performance will be much better than behind DOCSIS.
In any case, this new setup for sure has a lot of capacity to connect many more more users to this network. At this point we can still only offer E1 PRI interfaces. I expect that at some point during the coming winter the project for remote TDMoIP BRI (S/T, S0-Bus) connectivity will become available.
Acknowledgements
I'd like to thank anyone helping this effort, specifically * Sylvain "tnt" Munaut for his work on the RS422 interface board (+ gateware/firmware) * noris.net for sponsoring the co-location * sysmocom for sponsoring the EPYC server hardware
Almost one year after my post regarding first steps towards a V5 implementation, some friends and I were finally able to visit Wobcom, a small German city carrier and pick up a lot of decommissioned POTS/ISDN/PDH/SDH equipment, primarily V5 access networks.
This means that a number of retronetworking enthusiasts now have a chance to play with Siemens Fastlink, Nokia EKSOS and DeTeWe ALIAN access networks/multiplexers.
My primary interest is in Nokia EKSOS, which looks like an rather easy, low-complexity target. As one of the first steps, I took PCB photographs of the various modules/cards in the shelf, take note of the main chip designations and started to search for the related data sheets.
In short: Unsurprisingly, a lot of Infineon analog and digital ICs for the POTS and ISDN ports, as well as a number of Motorola M68k based QUICC32 microprocessors and several unknown ASICs.
So with V5 hardware at my disposal, I've slowly re-started my efforts to implement the LE (local exchange) side of the V5 protocol stack, with the goal of eventually being able to interface those V5 AN with the Osmocom Community TDM over IP network. Once that is in place, we should also be able to offer real ISDN Uk0 (BRI) and POTS lines at retrocomputing events or hacker camps in the coming years.
If you have ever worked with Digium (now part of Sangoma) digital telephony interface cards such as the TE110/410/420/820 (single to octal E1/T1/J1 PRI cards), you will probably have seen that they always have a timing connector, where the timing information can be passed from one card to another.
In PDH/ISDN (or even SDH) networks, it is very important to have a synchronized clock across the network. If the clocks are drifting, there will be underruns or overruns, with associated phase jumps that are particularly dangerous when analog modem calls are transported.
In traditional ISDN use cases, the clock is always provided by the network operator, and any customer/user side equipment is expected to synchronize to that clock.
So this Digium timing cable is needed in applications where you have more PRI lines than possible with one card, but only a subset of your lines (spans) are connected to the public operator. The timing cable should make sure that the clock received on one port from the public operator should be used as transmit bit-clock on all of the other ports, no matter on which card.
Unfortunately this decades-old Digium timing cable approach seems to suffer from some problems.
bursty bit clock changes until link is up
The first problem is that downstream port transmit bit clock was jumping around in bursts every two or so seconds. You can see an oscillogram of the E1 master signal (yellow) received by one TE820 card and the transmit of the slave ports on the other card at https://people.osmocom.org/laforge/photos/te820_timingcable_problem.mp4
As you can see, for some seconds the two clocks seem to be in perfect lock/sync, but in between there are periods of immense clock drift.
As I found out much later, this problem only occurs until any of the downstream/slave ports is fully OK/GREEN.
This is surprising, as any other E1 equipment I've seen always transmits at a constant bit clock irrespective whether there's any signal in the opposite direction, and irrespective of whether any other ports are up/aligned or not.
But ok, once you adjust your expectations to this Digium peculiarity, you can actually proceed.
clock drift between master and slave cards
Once any of the spans of a slave card on the timing bus are fully aligned, the transmit bit clocks of all of its ports appear to be in sync/lock - yay - but unfortunately only at the very first glance.
When looking at it for more than a few seconds, one can see a slow, continuous drift of the slave bit clocks compared to the master :(
Some initial measurements show that the clock of the slave card of the timing cable is drifting at about 12.5 ppb (parts per billion) when compared against the master clock reference.
This is rather disappointing, given that the whole point of a timing cable is to ensure you have one reference clock with all signals locked to it.
The work-around
If you are willing to sacrifice one port (span) of each card, you can work around that slow-clock-drift issue by connecting an external loopback cable. So the master card is configured to use the clock provided by the upstream provider. Its other ports (spans) will transmit at the exact recovered clock rate with no drift. You can use any of those ports to provide the clock reference to a port on the slave card using an external loopback cable.
In this setup, your slave card[s] will have perfect bit clock sync/lock.
Its just rather sad that you need to sacrifice ports just for achieving proper clock sync - something that the timing connectors and cables claim to do, but in reality don't achieve, at least not in my setup with the most modern and high-end octal-port PCIe cards (TE820).
.gif)
.png)
.gif)
0 
