Google Fiber Webpass now available in Charlotte


Google Fiber Webpass has made its grand entrance in Queen City, Charlotte, North Carolina. Charlotte joins Austin,TX and Nashville,TN as locations where we offer two different options for fast, reliable internet- available either through our fiber-to-the-home network or a simple but powerful combination of fiber-optic and wireless technology.


Thumbnail

Google Fiber Webpass is a point to point wireless technology that links apartments, condominiums and offices through millimeter wave and wireless radio technology connecting more people to high speed internet in a concentrated populated area. This option offers browsing speeds of up to 1 Gig through a mesh network that utilizes both wireless and fiber optic components.


Charlotte, NC has become a thriving city and is ranked high as one of the best places to live and also one of the fastest growing cities in the U.S. Access to fast and reliable internet will provide enhanced opportunities for residents to study and work from home, stream favorite shows and enjoy gaming online. Condominiums like The Madison have started enjoying the benefits of Google Fiber Webpass. We will continue converting one Ethernet-wired building at a time- allowing more and more residents to stay connected, furthering our commitment towards fast and reliable internet service for everyone.


The Google Fiber Charlotte Team is excited to bring the option of high speed internet service via Google Fiber Webpass to Charlotteans. To find out if service will be available in your building, check availability here.


Posted by David Scott, Senior Real Estate Partnership Lead Google Fiber


The Story of Gateway API

Earlier this week, Gateway API v1.0 was released, marking the significant milestone of General Availability. This Kubernetes API represents the future of load balancing, routing, and service mesh configuration. It already has more than 20 implementations, including GKE and Istio. In this post, we’ll take a look back at some of the key moments that led to this point, starting with the proposal that started it all.

Initial Proposal

The core ideas for this new API were initially proposed by Bowei Du (Software Engineer, Google) at KubeCon San Diego as “Ingress v2”, the next generation of the Ingress API for Kubernetes. This proposal came as the shortcomings of the original Ingress API were becoming apparent. The community had started to develop alternative APIs, notably including Istio’s VirtualService API and Contour’s IngressRoute API. We had reached an inflection point where the Kubernetes ecosystem was diverging, and Bowei believed it was important to develop a new standard that would expose all these advanced features in a portable way.

The initial proposal for this API provided a great foundation to build on. Specifically, this proposal focused on a role-oriented model that split capabilities into resources that were aligned with 3 different personas. It emphasized both expressiveness and extensibility as core design principles. This early sketch from that proposal closely resembles the API today:

Sketch of early proposal for Ingress API

One of the key limitations of the Ingress API was that it was designed with the lowest common denominator in mind: every feature included in the API needed to be implemented by everyone. This meant that the API surface was very small, and implementations that wanted to support more advanced features either relied on long lists of implementation-specific annotations or developing new custom APIs.

Bowei proposed that this new API could introduce a concept of “support levels.” This would allow us to add features to the API even if not every implementation could support them, for example “Extended” features would be fully portable if they were supported.Diagram showing proposed Custom API support levels

Evolution of the API

Since that initial proposal, the API has evolved significantly, benefiting from the expertise of many in the community. Gateway has been referred to as the “most collaborative API in Kubernetes history” due to the hundreds of contributors representing dozens of companies that have helped refine the API over the years.

One of the things that makes this API unique is that it is built on top of Custom Resource Definitions (CRDs). This has meant that Gateway API is developed and released outside of the main Kubernetes project, enabling broader collaboration and shorter feedback loops. For example, each new release of this API supports the 5 most recent versions of Kubernetes, covering the vast majority of clusters in use today. So, instead of waiting until you can upgrade to the latest version of Kubernetes, most will be able to try out these APIs close to the time they’re released.

As the first official Kubernetes API to take this approach, it has developed several unique concepts along the way:

GEPs

Similar to Kubernetes Enhancement Proposals (KEPs), Gateway Enhancement Proposals provide a streamlined approach for proposing significant new enhancements to Gateway API. As the API grew and attracted more contributors, it became critical to have a better way to document key design decisions. The concept of GEPs was initially proposed by Bowei in 2021.

More than 30 of these have already merged, with many more in progress right now. This pattern has been invaluable in keeping track of when and why key design decisions were made. All key parts of the API now have GEPs documenting when and why they were proposed, along with alternatives considered.

Release Channels

In 2021 we proposed a simplified approach to versioning that would introduce the concept of release channels, our own version of Kubernetes’ “feature gates”, which denote the stability of individual fields and features.

All new resources, fields, and features start in the “Experimental” release channel. As the name implies, this channel provides no stability guarantees and can include breaking changes to enable us to iterate more quickly on APIs.

As these experimental APIs stabilize, individual resources, fields, and features can graduate to the “Standard” release channel when they meet predefined graduation criteria. These two release channels enable us to both provide a stable and predictable API with the “Standard” release channel while still iterating on experimental concepts with the “Experimental” release channel.

Conformance Tests

We added the first conformance tests in 2022, before this API reached beta, and since then these tests have become a key part of every new feature in Gateway API, ensuring that implementations were truly providing a portable experience. Before a feature can graduate to the “Standard” release channel, thorough conformance tests need to be developed, and multiple implementations need to pass them.

Service Mesh Support

Earlier this year, mesh support launched its “Experimental” version, marking the first time a Kubernetes API has ever officially underpinned the concept of Service Mesh. In 2022, key Service Mesh projects came together to form the GAMMA initiative (Gateway API for Mesh Management and Administration). The core idea was that the Gateway API was sufficiently modular that the Routing and Policy layers could be used for both mesh and ingress use cases.

Trying it Out

Gateway API enables great new features on GKE, such as advanced multi-cluster routing. Yesterday GKE announced GA support for multi-cluster Gateways. In the coming weeks, GKE will also be rolling out the v1.0 CRDs for all customers that have enabled Gateway API in their clusters. In the meantime, you can access all of the same features with the v1beta1 CRDs already supported by GKE. For more information on how to get started with the Gateway API on GKE, refer to the GKE Gateway documentation.

If you’re interested in Gateway API’s support for Service Mesh, you can try it out with Anthos Service Mesh.

Alternatively, if you’d like to use this API with another implementation, refer to the open source project’s Getting Started documentation.

By Rob Scott – GKE Networking

Zero-shot adaptive prompting of large language models

Recent advances in large language models (LLMs) are very promising as reflected in their capability for general problem-solving in few-shot and zero-shot setups, even without explicit training on these tasks. This is impressive because in the few-shot setup, LLMs are presented with only a few question-answer demonstrations prior to being given a test question. Even more challenging is the zero-shot setup, where the LLM is directly prompted with the test question only.

Even though the few-shot setup has dramatically reduced the amount of data required to adapt a model for a specific use-case, there are still cases where generating sample prompts can be challenging. For example, handcrafting even a small number of demos for the broad range of tasks covered by general-purpose models can be difficult or, for unseen tasks, impossible. For example, for tasks like summarization of long articles or those that require domain knowledge (e.g., medical question answering), it can be challenging to generate sample answers. In such situations, models with high zero-shot performance are useful since no manual prompt generation is required. However, zero-shot performance is typically weaker as the LLM is not presented with guidance and thus is prone to spurious output.

In “Better Zero-shot Reasoning with Self-Adaptive Prompting”, published at ACL 2023, we propose Consistency-Based Self-Adaptive Prompting (COSP) to address this dilemma. COSP is a zero-shot automatic prompting method for reasoning problems that carefully selects and constructs pseudo-demonstrations for LLMs using only unlabeled samples (that are typically easy to obtain) and the models’ own predictions. With COSP, we largely close the performance gap between zero-shot and few-shot while retaining the desirable generality of zero-shot prompting. We follow this with “Universal Self-Adaptive Prompting“ (USP), accepted at EMNLP 2023, in which we extend the idea to a wide range of general natural language understanding (NLU) and natural language generation (NLG) tasks and demonstrate its effectiveness.


Prompting LLMs with their own outputs

Knowing that LLMs benefit from demonstrations and have at least some zero-shot abilities, we wondered whether the model’s zero-shot outputs could serve as demonstrations for the model to prompt itself. The challenge is that zero-shot solutions are imperfect, and we risk giving LLMs poor quality demonstrations, which could be worse than no demonstrations at all. Indeed, the figure below shows that adding a correct demonstration to a question can lead to a correct solution of the test question (Demo1 with question), whereas adding an incorrect demonstration (Demo 2 + questions, Demo 3 with questions) leads to incorrect answers. Therefore, we need to select reliable self-generated demonstrations.

Example inputs & outputs for reasoning tasks, which illustrates the need for carefully designed selection procedure for in-context demonstrations (MultiArith dataset & PaLM-62B model): (1) zero-shot chain-of-thought with no demo: correct logic but wrong answer; (2) correct demo (Demo1) and correct answer; (3) correct but repetitive demo (Demo2) leads to repetitive outputs; (4) erroneous demo (Demo3) leads to a wrong answer; but (5) combining Demo3 and Demo1 again leads to a correct answer.

COSP leverages a key observation of LLMs: that confident and consistent predictions are more likely correct. This observation, of course, depends on how good the uncertainty estimate of the LLM is. Luckily, in large models, previous works suggest that the uncertainty estimates are robust. Since measuring confidence requires only model predictions, not labels, we propose to use this as a zero-shot proxy of correctness. The high-confidence outputs and their inputs are then used as pseudo-demonstrations.

With this as our starting premise, we estimate the model’s confidence in its output based on its self-consistency and use this measure to select robust self-generated demonstrations. We ask LLMs the same question multiple times with zero-shot chain-of-thought (CoT) prompting. To guide the model to generate a range of possible rationales and final answers, we include randomness controlled by a “temperature” hyperparameter. In an extreme case, if the model is 100% certain, it should output identical final answers each time. We then compute the entropy of the answers to gauge the uncertainty — the answers that have high self-consistency and for which the LLM is more certain, are likely to be correct and will be selected.

Assuming that we are presented with a collection of unlabeled questions, the COSP method is:

  1. Input each unlabeled question into an LLM, obtaining multiple rationales and answers by sampling the model multiple times. The most frequent answers are highlighted, followed by a score that measures consistency of answers across multiple sampled outputs (higher is better). In addition to favoring more consistent answers, we also penalize repetition within a response (i.e., with repeated words or phrases) and encourage diversity of selected demonstrations. We encode the preference towards consistent, un-repetitive and diverse outputs in the form of a scoring function that consists of a weighted sum of the three scores for selection of the self-generated pseudo-demonstrations.
  2. We concatenate the pseudo-demonstrations into test questions, feed them to the LLM, and obtain a final predicted answer.
Illustration of COSP: In Stage 1 (left), we run zero-shot CoT multiple times to generate a pool of demonstrations (each consisting of the question, generated rationale and prediction) and assign a score. In Stage 2 (right), we augment the current test question with pseudo-demos (blue boxes) and query the LLM again. A majority vote over outputs from both stages forms the final prediction.

COSP focuses on question-answering tasks with CoT prompting for which it is easy to measure self-consistency since the questions have unique correct answers. But this can be difficult for other tasks, such as open-ended question-answering or generative tasks that don’t have unique answers (e.g., text summarization). To address this limitation, we introduce USP in which we generalize our approach to other general NLP tasks:

  • Classification (CLS): Problems where we can compute the probability of each class using the neural network output logits of each class. In this way, we can measure the uncertainty without multiple sampling by computing the entropy of the logit distribution.
  • Short-form generation (SFG): Problems like question answering where we can use the same procedure mentioned above for COSP, but, if necessary, without the rationale-generating step.
  • Long-form generation (LFG): Problems like summarization and translation, where the questions are often open-ended and the outputs are unlikely to be identical, even if the LLM is certain. In this case, we use an overlap metric in which we compute the average of the pairwise ROUGE score between the different outputs to the same query.
Illustration of USP in exemplary tasks (classification, QA and text summarization). Similar to COSP, the LLM first generates predictions on an unlabeled dataset whose outputs are scored with logit entropy, consistency or alignment, depending on the task type, and pseudo-demonstrations are selected from these input-output pairs. In Stage 2, the test instances are augmented with pseudo-demos for prediction.

We compute the relevant confidence scores depending on the type of task on the aforementioned set of unlabeled test samples. After scoring, similar to COSP, we pick the confident, diverse and less repetitive answers to form a model-generated pseudo-demonstration set. We finally query the LLM again in a few-shot format with these pseudo-demonstrations to obtain the final predictions on the entire test set.


Key Results

For COSP, we focus on a set of six arithmetic and commonsense reasoning problems, and we compare against 0-shot-CoT (i.e., “Let’s think step by step“ only). We use self-consistency in all baselines so that they use roughly the same amount of computational resources as COSP. Compared across three LLMs, we see that zero-shot COSP significantly outperforms the standard zero-shot baseline.

Key results of COSP in six arithmetic (MultiArith, GSM-8K, AddSub, SingleEq) and commonsense (CommonsenseQA, StrategyQA) reasoning tasks using PaLM-62B, PaLM-540B and GPT-3 (code-davinci-001) models.

USP improves significantly on 0-shot performance. “CLS” is an average of 15 classification tasks; “SFG” is the average of five short-form generation tasks; “LFG” is the average of two summarization tasks. “SFG (BBH)” is an average of all BIG-Bench Hard tasks, where each question is in SFG format.

For USP, we expand our analysis to a much wider range of tasks, including more than 25 classifications, short-form generation, and long-form generation tasks. Using the state-of-the-art PaLM 2 models, we also test against the BIG-Bench Hard suite of tasks where LLMs have previously underperformed compared to people. We show that in all cases, USP again outperforms the baselines and is competitive to prompting with golden examples.

Accuracy on BIG-Bench Hard tasks with PaLM 2-M (each line represents a task of the suite). The gain/loss of USP (green stars) over standard 0-shot (green triangles) is shown in percentages. “Human” refers to average human performance; “AutoCoT” and “Random demo” are baselines we compared against in the paper; and “3-shot” is the few-shot performance for three handcrafted demos in CoT format.

We also analyze the working mechanism of USP by validating the key observation above on the relation between confidence and correctness, and we found that in an overwhelming majority of the cases, USP picks confident predictions that are more likely better in all task types considered, as shown in the figure below.

USP picks confident predictions that are more likely better. Ground-truth performance metrics against USP confidence scores in selected tasks in various task types (blue: CLS, orange: SFG, green: LFG) with PaLM-540B.

Conclusion

Zero-shot inference is a highly sought-after capability of modern LLMs, yet the success in which poses unique challenges. We propose COSP and USP, a family of versatile, zero-shot automatic prompting techniques applicable to a wide range of tasks. We show large improvement over the state-of-the-art baselines over numerous task and model combinations.


Acknowledgements

This work was conducted by Xingchen Wan, Ruoxi Sun, Hootan Nakhost, Hanjun Dai, Julian Martin Eisenschlos, Sercan Ö. Arık, and Tomas Pfister. We would like to thank Jinsung Yoon Xuezhi Wang for providing helpful reviews, and other colleagues at Google Cloud AI Research for their discussion and feedback.

Source: Google AI Blog


Alpha Release of Telecom Library

Posted by Luke Hopkins - Developer Relations Engineer

Today we’re thrilled to announce that the Telecom jetpack library is now in alpha for developers who already have or are interested in creating voice and/or video calling applications. Our aim with this library is to simplify the developer integration process and improve VoIP calling across Android surfaces.

androidx.core:core-telecom:1.0.0-alpha02

What’s in the Public Alpha release

This release supports a variety of Telecom features, including:

Platform synchronization

For surfaces like watches, this library allows the user to answer, decline, hang up and mute your call through a simple API, as well as displaying useful information such as who the caller is.

ALT TEXT

This is also beneficial because if the device is aware of your call, should other calls such a PTSN/SIM based call come through, you can give the user a chance to hold the call they are currently on.

Dedicated foreground support

With the changes to Android 14, which require applications to specify foreground service types, this library takes care of the requirements for you. For more information, please refer to the foreground service documentation.

Foreground support allows users to stay connected to their calls even after the user has navigated away from your app... You won’t need to build your own foreground services or worry about the background state of your application.

Audio Routing

Instead of using the audio manager to track state, focus and obtain a list of audio devices, this Telecom library will list all available endpoints to your application for streaming audio to/from Bluetooth hearables, hearing aids, wired headphones, and other surfaces, thus giving users access and control to a wide range of hearable devices.

Backwards Compatibility

Backwards compatibility works all the way down to Android O (API Level 26) on devices which support the Telecom stack which means implementing the simple API surface below supports a wide range of devices.

callsManager.addCall(
        attributes,
        onIsCallAnswered,
        onIsCallDisconnected,
        onIsCallActive,
        onIsCallInactive
       ){


        val callScope=this

}

You can also query the packagemanager to know if the device supports Telecom.

packagemanager.hasSystemFeature(PackageManager.FEATURE_TELECOM)

Why use this library over Platform API

You might be thinking, why make this move to a new library when I could just similarly migrate the deprecated APIs to the new APIs added in Android 14. Well this library offers:

New Features

We will have more exciting additions coming to the Telecom library in the coming months which are exclusive to the jetpack library. These included expanded support for VoIP Call actions such as being able to locally mute the VoIP app for the specific call and being able to display the name of the speaker on another surface such as Android Auto. We also have a new feature coming soon that will allow users to transfer their ongoing VoIP calls between their phones and tablets.

Backward Compatibility

As previously stated, this library supports backward compatibility, which means that your app will not only be supported on a wider range of devices, but we can resolve interoperability issues with older Android versions.

A simple API surface and a large coverage of devices, means this library is the goto solution for calling applications.

Migrating from ConnectionService to CallsManager

Even if you already have an existing ConnectionService integration for your VoIP app, you should consider migrating to CallsManager, as mentioned above we have a lot of exciting features coming to this library and using the jetpack library will give you a simple and complete solution moving forward.

Migrating from ConnectionService to CallManager is fairly straightforward to implement but is not a simple case of changing namespace. You can think of CallManager representing ConnectionService and CallControlScope representing ConnectionService.

Below shows the difference between how to switch audio using connection service to CallControlScope.

You can also query the packagemanager to know if the device supports Telecom.

cconnectionService.setAudioRoute (int route)

InCallService- Android 13

when (requestEndpointChange(newEndpoint)) { 

     is CallControlResult.Success -> { 
                                      // Device changed 
          } 

          is CallControlResult.Error -> { 

          } 
  }

Jetpack Library

Another example showing how simple this API is to use, you can add a call to the platform and define you call attributes with the code below:

val attributes = CallAttributesCompat( 
       displayName = displayName, 
              address = address,
       direction = CallAttributesCompat.DIRECTION_INCOMING,
       callType = CallAttributesCompat.CALL_TYPE_AUDIO_CALL,
       callCapabilities = (CallAttributesCompat.SUPPORTS_SET_INACTIVE
                or CallAttributesCompat.SUPPORTS_STREAM 
                               or CallAttributesCompat.SUPPORTS_TRANSFER), 
)
callsManager.addCall(
        attributes
      ) { 
                // Call control scope 

}


From here you will have a call control scope and this scope you can answer, hold, disconnect and get a list of hearable devices.

//call control scope 
launch { 
            availableEndpoints.collect { 

             ..... 

            }

          }

Getting started

Head over to our updated developer guide to get started and try out the Public Alpha release of the Telecom library. Make sure to check out our sample app found on GitHub for a demonstration on how to work with the various APIs.

This sample application implements all the latest features for the Telecom library showing how to do:

  • Audio Routing
  • Foreground Services
  • Accept, Disconnect, Reject and Hold calls
  • Watch integration
  • CallStyle notification

Feedback

We’d love to hear from you during this Alpha launch to help us shape the library and influence future roadmapping, so please share your feedback and let us know your experience with the library!

1:1 video calling in the Google Meet mobile app is now available

What’s changing

You can now make cloud-encrypted 1:1 video calls to other users in your organization using the Meet mobile app. Previously, you had to create a meeting link ahead of time, which could then be shared in a calendar invite, chat, or email. Now you can place a Meet call on your mobile app directly to a colleague, ringing their mobile device. Within the call, you’ll also have access to the latest Meet features including in-meeting chat, virtual backgrounds and visual effects, live closed captions, and more depending on your Workspace edition. 
1:1 video calling in the Google Meet mobile app is now available

Getting started 

  • Admins: This feature will be ON by default and can only be turned OFF by turning off Meet meetings and calls for your organization
    • Alternatively, you can deploy the Google Meet (Original) app from Google Play or the App Store to managed devices if you do not wish for users to have calling capabilities (outbound and inbound calls). 
    • Note: We will introduce admin controls to restrict inbound calls next year. We’ll provide an update here on the Workspace Updates Blog when more information is available. 
    • If you have legacy calling enabled for your users, they will have access to features previously found in Duo (group calls, messages, moments, family mode, etc.) if they have not upgraded to the new Meet app. 
  • End users: 
    • Meet calls do not include legacy calling features previously found in Duo (group calls, messages, moments, family mode, knock knock) but those continue to be available if you have not upgraded to the new Meet app and are using legacy calling
    • Visit the Help Center to learn how to make Meet Calls with Google Meet and to learn about the new Google Meet app

Rollout pace 

iOS: 

Android: 

Availability 

  • Available to all Google Workspace customers 

Resources 

Increasing trust for embedded media

Posted by the Android team

Android WebView is a powerful and flexible API that Android developers can use to embed media in their apps, and continually improving its security and privacy protections is a top priority for our team. For example, embedded media providers should be able to verify that their media is playing in a trusted and safe environment. Android app developers and SDK providers already have solutions for this, including attestation services like the Play Integrity API and Firebase App Check, which preserve user privacy while enabling developers to verify their apps’ server requests. Today, app developers are able to pass information from these attestation services to embedded content providers; however, the current process is neither simple nor scalable. That’s why we’re piloting an experimental Android WebView Media Integrity API with select embedded media providers early next year.

How does this relate to the Web Environment Integrity API proposal?

We’ve heard your feedback, and the Web Environment Integrity proposal is no longer being considered by the Chrome team. In contrast, the Android WebView Media Integrity API is narrowly scoped, and only targets WebViews embedded in apps. It simply extends existing functionality on Android devices that have Google Mobile Services (GMS) and there are no plans to offer it beyond embedded media, such as streaming video and audio, or beyond Android WebViews.

What is the challenge with Android WebViews?

The Android WebView API lets app developers display web pages which embed media, with increased control over the UI and advanced configuration options to allow a seamless integration in the app. This brings a lot of flexibility, but it can be used as a means for fraud and abuse, because it allows app developers to access web content, and intercept or modify user interactions with it. While this has its benefits when apps embed their own web content, it does not prohibit bad actors from modifying content and, by proxy, misrepresenting its source.

What functionality are we bringing to embedded Android WebView media?

This sequence diagram shows a user requesting media in an Android app and the Android app returning the media in a manipulated WebView that could be used to alter the media and defraud the user.

The new Android WebView Media Integrity API will give embedded media providers access to a tailored integrity response that contains a device and app integrity verdict so that they can ensure their streams are running in a safe and trusted environment, regardless of which app store the embedding app was installed from. These verdicts are simple, low entropy metadata about the app and device and don’t contain any user or device identifiers. Unlike apps and games using Play Integrity API, media providers will not obtain the app’s Play licensing status and apps will also be able to exclude their package name from the verdict if they choose. Our goal for the API is to help sustain a thriving and diverse ecosystem of media content in Android apps, and we’re inviting media content providers to express interest in joining an early access program early next year.

Launching Structured Data Files v7

Today we’re announcing the general availability of Structured Data Files (SDF) v7. All users can now use v7 when uploading and downloading SDFs in the Display & Video 360 UI or downloading SDFs through the Display & Video 360 API.

The following material and superficial changes have been made from v6 to v7 to decouple SDF from the deprecated Entity Read Files tool and add support for newer Display & Video 360 features:

Full details on the changes made in v7 can be found in our Structured Data Files release notes. Instructions on migrating from SDF v6 to v7 can be found in our migration guide.

If you run into issues or need help with this new version, please contact us using our support contact form.