fidzu : mobile

While everyone seems caught up with sizzling summer comedies and sun-drenched dramas, there's something we keep coming back…

12 May 2026 3:30pm GMT

Grab your magnifying glass and your favorite Scooby Snack-everyone's favorite gang of teen detectives headed back to where…

12 May 2026 3:00pm GMT

Looking for a Chilean miniseries to shake up your streaming list? Against expectation, "Someone Must Know"-streaming on Netflix…

12 May 2026 6:30am GMT

Practicing gratitude may decrease symptoms of depression and anxiety, and improve mental health and life satisfaction¹. Consistent gratitude practice may lead to sustained improvements that last months². 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 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:

adb shell device_config put systemui

generated_preview_api_reset_interval_ms 0

All of their efforts have made the Gratitude widget high quality and differentiated.

The Solution Part 2: promote new widgets in-app

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:

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.

"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

08 May 2026 4:00pm GMT

The mobile ecosystem is always evolving, bringing both new opportunities and new threats. Through these changes, Android and Google Play remain committed to ensuring that billions of users can continue to enjoy their apps with confidence and developer innovation can thrive. Earlier this year, we shared how Android and Google Play kept the ecosystem safe in 2025 by deepening our investments in AI and real-time defenses. Today, we're giving you a look at how we're making it easier and faster than ever for millions of developers to publish safer apps.

07 May 2026 5:00pm GMT

Karrot is a hyperlocal, community-driven peer-to-peer marketplace app that enables users to buy, sell, and trade items with other verified users. Since launching in South Korea in 2015, the platform has expanded into global markets, amassing over 43 million registered users.

After launching in North America, engineers at Karrot observed that 30% of users in the region use a non-English device language, such as Spanish. To make the app more accessible, the team wanted to bring seamless translation functionality to Karrot quickly and at scale. The developers determined that the most efficient way to implement quality translations would be through integrating an AI service directly into the app, so they selected the Firebase AI Logic and its Android SDK to access Gemini Flash Lite, which led to higher purchasing conversion among non-English users.

Integrating Gemini Firebase AI Logic

The team initially tested two on-device options: the ML Kit Translation SDK and Gemini Nano. But the team found challenges with each: ML Kit Translation didn't meet the team's quality expectations, and Gemini Nano, if it isn't already on the device, required the user to download the model data.

The team then tested Firebase AI Logic. By calling the Gemini API directly from the app, Firebase AI Logic delivered accuracy at speeds that mirrored a natural conversational cadence.

Integrating Firebase AI Logic into the app was a "remarkably straightforward experience," according to TaeGyu An, an Android Software Engineer on Karrot's Mobile Platform team. TaeGyu and the team used the platform's documentation and code samples to build a proof of concept in under three hours.

This allowed the team to spend more time refining prompts and finding optimal configuration values. "Even without extensive experience writing prompts, the official documentation's guides and tips made it easy to quickly identify the right direction for improving translation quality," said WonJoong Lee, an Android Software Engineer on Karrot's North America Product Team.

This low barrier to entry and rapid turnaround time enabled engineers to keep development costs low and go from proof of concept to production code in just two weeks-all without setting up a dedicated backend. That also freed up time to focus on UX and policy design, such as opt-in behavior and the conditions for the translation banner.

Driving sales with enhanced AI features

Since implementing translation using Gemini and Firebase AI Logic, the Karrot team observed higher purchasing conversion among non-English users, indicating that the translation feature is helping drive sales.

Of users who used a non-English device language, one in three of them who were shown the translation banner actively used the feature. The team has also observed that buyers offered translation functionality were 2.4X more likely to start a chat with a seller than those who weren't.

The flexibility and simplicity of deploying Firebase AI Logic has led the team to explore other features to simplify the workstreams of its engineers. "It's rewarding to build features that scale across diverse Android devices while helping neighbors connect and interact within their local communities," concluded TaeGyu.

Going forward, the team plans to implement Server Prompt Templates to adjust prompts after release without shipping a new version of the app. This, combined with Remote Config, should help the team iterate faster and reduce operational overhead.

Get started

Learn how to build Gemini-enabled features like AI translations and in-app personalization and more with Firebase AI Logic to deliver better experiences to your users, faster.

04 May 2026 5:00pm GMT

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.

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.

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.

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.

0 0

26 Jan 2026 9:34am GMT

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:

cat /tmp/log.txt | meow appsinknewsample n:V0 n:video ht: \
ft:-0:00:21.466607596 's:#([A-za-z][A-Za-z]*/)*#'

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

05 Dec 2025 11:16am GMT

• Release announcement on itch.io

1 0

15 Oct 2025 11:31am GMT

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.

• a Livingston Portmaster3 RAS server

• a Cisco AS5400 RAS server

For more details, see this wiki page and this ticket

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.

18 Sep 2022 10:00pm GMT

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.

The results can be found in the Osmocom retronetworking wiki, with https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS being the main entry page, and sub-pages about

• Node Control Unit

• 16x BRI Uk0 Line Card

• 32x POTS Line Card

• Line Measurement Unit

• Shelf

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.

08 Sep 2022 10:00pm GMT

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.

08 Sep 2022 10:00pm GMT