fidzu : smartphone

Posted by Maru Ahues Bouza - Product Management Director, Android Developer

Yesterday's Galaxy Unpacked event from Samsung debuted the latest in foldables, wearables, and more! The event introduced the Galaxy Z Fold6 and Z Flip6 and the Galaxy Watch7 and Watch Ultra - and it has never been easier to build apps that look great across all these screen sizes and types. To help you get your apps ready for the latest Android devices, we're sharing how you can prepare your app for Wear OS 5 and how to build adaptive apps that scale across mobile, tablets, foldables and more!

Get your app ready for Wear OS 5

Samsung's new Galaxy Watch lineup, including the Watch Ultra and Watch7, will be the first smartwatches powered by Wear OS 5, the latest version of the Wear OS platform. As Wear OS 5 is based on Android 14, this new platform version brings with it a number of developer-facing changes. To ensure your app is ready for the next generation of devices, start by testing your app on the Wear OS 5 Emulator!

Wear OS 5 brings the next iteration of the Watch Face Format, providing more features to create expressive, efficient and individual watch faces for your users. New watches launched with Wear OS 5 will only support third-party watch faces built with Watch Face Format, prioritizing the user experience. For more information on watch face compatibility, see this Help Center article.

As we gather momentum behind the Watch Face Format, we're changing requirements for publishing watch faces on Google Play. Check out the watch face page for the latest guidance.

Build adaptive to scale across screen sizes and types

The latest in large screens and foldables are here, with the new Galaxy Z Fold6 and Z Flip6, so there is even more reason to ensure your app looks great across whatever screen size or folded state your users are engaging with. The best way to do that is to make your app adaptive - meaning your users get an optimal experience on all their devices. By building an adaptive app, you scale across mobile, tablets, foldables, desktop and more.

A great place to start when building adaptive apps is with the new Compose adaptive layout libraries. These libraries are designed to help you to make your UI look good across window sizes. From navigation UI to list/detail and supporting pane layouts, we're providing composables to make building an adaptive app easier than ever.

Additionally, window size classes are the best way to scale your UI, with opinionated breakpoints that help you design, develop, and test responsive/adaptive layouts across various window sizes. Window size classes enable you to change your app layout as the display space available to your app changes, for example, when a device folds or unfolds, the device orientation changes, or the app window is resized in multi‑window mode.

Discover everything you need to know about building adaptive apps with the adaptive apps documentation; it will be continually updated with the latest and greatest tools and APIs to enable you to scale across screens!

Get started with Adaptive Apps and Wear OS

With these new devices, from the smallest to the largest, there are opportunities to build apps that excite your users on all their favorite Android screens. Apps like SoundCloud, Peloton, and more are already building experiences that scale across their user's favorite screens!

Get building for Wear OS today by checking out Wear OS developer site and visiting the Wear OS gallery for inspiration. And scale your app across even more screens by building adaptive with the latest from Compose!

11 Jul 2024 6:30pm GMT

Posted by Robbie McLachlan, Developer Marketing

#WeArePlay celebrates the inspiring journeys of people behind apps and games on Google Play. In honor of Pride Month, we are highlighting founders who have built tools to empower the LGBTQIA+ community. From dating apps to mental health tools, to storytelling platforms - these founders are paving the way for more inclusive technology.

npckc is a game creator from Kanto, Japan whose stories portray the trans experience

Born in Hong Kong and raised in Canada, npckc is a trilingual translator based in Japan. A self-taught programmer, they create games that feature stories and characters which are often from marginalized communities. One such game is "one night, hot springs" where players follow Haru, a trans woman, as she embarks on a visit to the hot springs. Players have praised the game's realistic portrayal of trans experiences and the relaxing music composed by npckc's partner, sdhizumi. As a finalist in Google Play's Indie Games Festival in Japan, they hope to attend more gaming conventions to connect with fellow developers in person.

Anshul and Rohan from Mumbai, India built a mental health support app geared to the LGBTQIA+ community's needs

After Anshul returned to India from London, he met Rohan and the pair bonded over their mental health struggles. Together they shared a dream; to create something in the wellness space. This became Evolve, an app with guided meditations, breathing exercises, and daily affirmations. When the pandemic hit, the pair saw first-hand how underserved the LGBTQIA+ community was in mental health support. For Rohan, who identifies as a gay man, this realization hit close to home. Together, Anshul and Rohan redeveloped Evolve towards the LGBTQIA+ community's specific needs - building a safe space where users can share their experiences, seek mentorship, and build a supportive community.

BáiYù from Indiana, U.S. created a platform to publish authentic, queer visual novels and indie games

Queer developer BáiYù loves writing stories, and started making games at age 16. Part of a game-development community, BáiYù wanted an affordable way to help get their creations out. So they set up Project Ensō, publishing queer visual novels and narrative indie games. With 10 titles on Google Play, BáiYù supports other developers from under-represented groups to share their own authentic stories on Project Ensō, even polishing their games before release. The most popular title on Project Ensō is "Yearning: A Gay Story", in which gamers play a newly-out gay man navigating his freshman year of college. BáiYù's efforts have had a profound impact on players, with many sharing how these games have positively transformed their lives.

Alex and Jake from Nevada, U.S. built an inclusive dating app and social community for everyone

Alex and Jake grew up in an environment that didn't accept the LGBTQIA+ community. They started building apps together after a mutual friend introduced them. When they realized that queer people were looking for a platform that offered support and meaningful connections, they created Taimi. Taimi is not just a dating app for LGBTQIA+ people; it's also a social network where they can bond, build community, and feel safe. Alex and Jake are also proud to partner with NGOs that provide mental health support for the community.

Discover more stories of app and game creators in #WeArePlay.

28 Jun 2024 4:00pm GMT

Posted by Robbie McLachlan - Developer Marketing

Last year #WeArePlay went on a virtual tour of India, Europe and Japan to spotlight the stories of app and game founders. Today, we're continuing our tour across the world with our next stop: Australia

From an app helping people during natural disasters to a game promoting wellbeing through houseplants, meet the 50 apps and games companies building growing businesses on Google Play.

Let's take a quick road trip across the territories.

Tristan's app gives accurate information to people during natural disasters

Meet Tristan from Canberra, founder of Disaster Science. When Tristan was stranded by a bushfire with friends during a holiday, he realized the need to have accurate information in a crisis situation. Moved to help others, he leveraged his software development skills to create his app, Bushfire.io. It collects data from multiple sources to give people an overview of fires, floods, road closures, and vital weather updates.

He has recently added real-time satellite imagery and has plans to expand further internationally, with coverage of region-specific events like cyclones, earthquakes, evacuations and heat warnings.

Christine and Lauren's promotes wellbeing through houseplants

Friends Christine and Lauren from Melbourne co-founded gaming company Kinder World. As a child, Lauren used video games to soothe the pain of her chronic ear infections. That was how she discovered they could be a healing experience for people-a sentiment she dedicated her career to. She partnered with engineer Christina to make Kinder World: Cozy Plants.

In the game, players enter the comforting, botanical world of houseplants, home decoration, steaming hot coffee, and freshly baked cookies. Since going viral on several social media platforms, the app has seen huge growth.

Kathryn's app helps reduce stress and anxiety in children

Kathryn from Melbourne is the founder of Courageous Kids. When Kathryn's son was anxious and fearful whenever she dropped him off at school, as a doctor, her instincts for early intervention kicked in. She sought advice from pediatric colleagues to create stories to explain his day, making him the main character. Friends in a similar situation began to ask her for advice and use the stories for their own children so she created Courageous Kids.

A library of real-world stories for parents to personalize, Courageous Kids helps children to visualize their day and manage their expectations. Her app has become popular among families of sensitive and autistic children, and Kathryn is now working with preschools to give even more kids the tools to feel confident.

Discover more #WeArePlay stories from Australia, and stories from across the globe.

24 Jun 2024 4:00pm GMT

3D Gaussian splatting is the emerging rendering technique that is overtaking NeRFs. Since it is centered around point primitives, it is more compatible with traditional graphics pipelines that already support point rendering.

Gaussian splats essentially enhance the concept of point rendering by converting the point primitive into a 3D ellipsoid, which is then projected into 2D during the rendering process.. This concept was initially described in 2002 [3], but the technique of extending Structure from Motion scans in this way was only detailed more recently [1].

In this post, I explore how to integrate Gaussian splats into the traditional graphics pipeline. This allows them to be used alongside triangle-based primitives and interact with them through the depth buffer for occlusion (see header image). This approach also simplifies deployment by eliminating the need for CUDA.

Storage

The original implementation uses .ply files as their checkpoint format, focusing on maintaining training-relevant data structures at the expense of storage efficiency, leading to increased file sizes.

For example, it stores the covariance as scaling and a rotation quaternion, necessitating reconstruction during rendering. A more efficient approach would be to leverage orthogonality, storing only the diagonal and upper triangular vectors, thereby eliminating reconstruction and reducing storage requirements.

Further analysis of the storage usage for each attribute shows that the spherical harmonics of orders 1-3 are the main contributors to the file size. However, according to the ablation study in the original publication [1], these harmonics only lead to a modest PSNR improvement of 0.5.

Therefore, the most straightforward way to decrease storage is by discarding the higher-order spherical harmonics. Additionally, the level 0 spherical harmonics can be converted into a diffuse color and merged with opacity to form a single RGBA value. These simple yet effective methods were implemented in one of the early WebGL implementations, resulting in the .splat format. As an added benefit, this format can be easily interpreted by viewers unaware of Gaussian splats as a simple colored point cloud:

By directly storing the covariance as previously mentioned we can reduce the precision from float32 to float16, thereby halving the storage needed for that data. Furthermore, since most splats have limited spatial extents, we can also utilize float16 for position data, yielding additional storage savings.

With these changes, we achieve a storage requirement of 22 bytes per splat, in contrast to the 44 bytes needed by the .splat format and 236 bytes in the original implementation. Thus, we have attained a 10x reduction in storage compared to the original implementation simply by using more suitable data types.

Blending

The image formation model presented in the original paper [1] is similar to the NeRF rendering, as it is compared to it. This involves casting a ray and observing its intersection with the splats, which leads to front-to-back blending. This is precisely the approach taken by the provided CUDA implementation.

Blending remains a component of the fixed-function unit within the graphics pipeline, which can be set up for front-to-back blending [2] by using the factors (one_minus_dest_alpha, one) and by multiplying color and alpha in the shader as color.rgb * color.a. This results in the following equation:

\begin{aligned}C_{dst} &= (1 - \alpha_{dst}) \cdot \alpha_{src} C_{src} &+ C_{dst}\\ \alpha_{dst} &= (1 - \alpha_{dst})\cdot\alpha_{src} &+ \alpha_{dst}\end{aligned}

However, this method requires the framebuffer alpha value to be zero before rendering the splats, which is not typically the case as any previous render pass could have written an arbitrary alpha value.

A simple solution is to switch to back-to-front sorting and use the standard alpha blending factors (src_alpha, one_minus_src_alpha) for the following blending equation:

C_{dst} = \alpha_{src} \cdot C_{src} + (1 - \alpha_{src}) \cdot C_{dst}

This allows us to regard Gaussian splats as a special type of particles that can be rendered together with other transparent elements within a scene.

References

1. Kerbl, Bernhard, et al. "3d gaussian splatting for real-time radiance field rendering." ACM Transactions on Graphics 42.4 (2023): 1-14.
2. Green, Simon. "Volumetric particle shadows." NVIDIA Developer Zone (2008).
3. Zwicker, Matthias, et al. "EWA splatting." IEEE Transactions on Visualization and Computer Graphics 8.3 (2002): 223-238.

0 0

17 Jun 2024 1:28pm GMT

During all these years using GStreamer, I've been having to deal with GstSegments in many situations. I've always have had an intuitive understanding of the meaning of each field, but never had the time to properly write a good reference explanation for myself, ready to be checked at those times when the task at hand stops being so intuitive and nuisances start being important. I used the notes I took during an interesting conversation with Alba and Alicia about those nuisances, during the GStreamer Hackfest in A Coruña, as the seed that evolved into this post.

But what are actually GstSegments? They are the structures that track the values needed to synchronize the playback of a region of interest in a media file.

GstSegments are used to coordinate the translation between Presentation Timestamps (PTS), supplied by the media, and Runtime.

PTS is the timestamp that specifies, in buffer time, when the frame must be displayed on screen. This buffer time concept (called buffer running-time in the docs) refers to the ideal time flow where rate isn't being had into account.

Decode Timestamp (DTS) is the timestamp that specifies, in buffer time, when the frame must be supplied to the decoder. On decoders supporting P-frames (forward-predicted) and B-frames (bi-directionally predicted), the PTS of the frames reaching the decoder may not be monotonic, but the PTS of the frames reaching the sinks are (the decoder outputs monotonic PTSs).

Runtime (called clock running time in the docs) is the amount of physical time that the pipeline has been playing back. More specifically, the Runtime of a specific frame indicates the physical time that has passed or must pass until that frame is displayed on screen. It starts from zero.

Base time is the point when the Runtime starts with respect to the input timestamp in buffer time (PTS or DTS). It's the Runtime of the PTS=0.

Start, stop, duration: Those fields are buffer timestamps that specify when the piece of media that is going to be played starts, stops and how long that portion of the media is (the absolute difference between start and stop, and I mean absolute because a segment being played backwards may have a higher start buffer timestamp than what its stop buffer timestamp is).

Position is like the Runtime, but in buffer time. This means that in a video being played back at 2x, Runtime would flow at 1x (it's physical time after all, and reality goes at 1x pace) and Position would flow at 2x (the video moves twice as fast than physical time).

The Stream Time is the position in the stream. Not exactly the same concept as buffer time. When handling multiple streams, some of them can be offset with respect to each other, not starting to be played from the begining, or even can have loops (eg: repeating the same sound clip from PTS=100 until PTS=200 intefinitely). In this case of repeating, the Stream time would flow from PTS=100 to PTS=200 and then go back again to the start position of the sound clip (PTS=100). There's a nice graphic in the docs illustrating this, so I won't repeat it here.

Time is the base of Stream Time. It's the Stream time of the PTS of the first frame being played. In our previous example of the repeating sound clip, it would be 100.

There are also concepts such as Rate and Applied Rate, but we didn't get into them during the discussion that motivated this post.

So, for translating between Buffer Time (PTS, DTS) and Runtime, we would apply this formula:

Runtime = BufferTime * ( Rate * AppliedRate ) + BaseTime

And for translating between Buffer Time (PTS, DTS) and Stream Time, we would apply this other formula:

StreamTime = BufferTime * AppliedRate + Time

And that's it. I hope these notes in the shape of a post serve me as reference in the future. Again, thanks to Alicia, and especially to Alba, for the valuable clarifications during the discussion we had that day in the Igalia office. This post wouldn't have been possible without them.

0 0

30 Apr 2024 6:00am GMT

Just a quick update on something that I've been working on in my free time.

I recently refurbished my old Nintendo Wii, and for some reason I cannot yet explain (not even to myself) I got into homebrew programming and decided to port libSDL (the 2.x version -- a 1.x port already existed) to it. The result of this work is already available via the devkitPro distribution, and although I'm sure there are still many bugs, it's overall quite usable.

In order to prove it, I ported the game VVVVVV to the Wii:

During the process I had to fix quite a few bugs in my libSDL port and in a couple of other libraries used by VVVVVV, which will hopefully will make it easier to port more games. There's still an issue that bothers me, where the screen resolution seems to be not totally supported by my TV (or is it the HDMI adaptor's fault?), resulting in a few pixels being cut at the top and at the bottom of the screen. But unless you are a perfectionist, it's a minor issue.

In case you have a Wii to spare, or wouldn't mind playing on the Dolphin emulator, here's the link to the VVVVVV release. Have fun! :-)

0 0

02 Feb 2024 5:50pm 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