[Bug]: CarPlay map view never sets GMSMapViewOptions.screen, so the navigation header and footer are sized for the phone

Abierto
  • ¿Algo no está bien?
#640 4 comentarios 1 reacción 1 asignado Ver en GitHub

Los mantenedores suelen responder en 5 días

@jokerttu ya está trabajando en esto.

Desde el 28/8/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Is there an existing issue for this?
  • I have searched the existing issues
Description of the bug

On a physical CarPlay head unit, a map view rooted in the CPWindow by BaseCarSceneDelegate renders its navigation UI at phone size. The guidance header's lane-guidance dropdown overlaps the ETA footer, and the type is far too large for the display. The map tiles and labels render correctly — only the navigation overlay is mis-sized.

GMSMapViewOptions has a screen property, added by the Navigation SDK's own category:

The screen the view will be used on.

Defaults to the main screen. Should be set to the CarPlay screen if this map view is to be used with CarPlay.

— GMSMapViewOptions+Navigation.h, GoogleNavigation 10.13.0

NavViewController.loadView never sets it:

GMSMapViewOptions *options = [[GMSMapViewOptions alloc] init];

if (_mapId && ![_mapId isEqualToString:@""]) {
  options.mapID = [GMSMapID mapIDWithIdentifier:_mapId];
}

if (_initialCameraPosition) {
  options.camera = _initialCameraPosition;
}

_mapView = [[GMSMapView alloc] initWithOptions:options];   // options.screen unset

grep -rn -i "uiscreen\|options.screen" ios example/ios/SampleApp at main returns nothing — not in the library, not in the CarPlay sample app. So every map view the library creates, including the one BaseCarSceneDelegate roots in the CPWindow, believes it is on UIScreen.mainScreen.

That the SDK does adapt to CarPlay is documented in GMSUISettings+Navigation.h: the trip progress bar "will not be shown for CarPlay displays" and "will only be shown when the GMSMapView is at least 552pt tall". It branches on the display and on height, and options.screen appears to be the public input for that — which the bridge never provides.

This is only visible if the app enables the navigation header/footer on the car screen. BaseCarSceneDelegate.onSessionAttached disables both by default and the sample does not override them, which is likely why it has gone unnoticed. Turning them on is the natural thing to do for an app that wants Google's turn-by-turn chrome on the console rather than building its own from didChangeNavInfo (per the guidance in #508).

Applications cannot work around this themselves: screen is an init-time option, there is no setter on GMSMapView, and NavViewController constructs the map view internally. It needs a fix in the library.

Suggested fix

Let the screen be supplied before the view loads, and have BaseCarSceneDelegate pass the car window's screen:

// NavViewController.h
- (void)setScreen:(nullable UIScreen *)screen;

// NavViewController.mm
- (void)setScreen:(nullable UIScreen *)screen {
  if (_mapView != nil) {
    RCTLogWarn(@"Cannot change screen after view is loaded");
    return;
  }
  _screen = screen;
}

// ... in loadView, before initWithOptions:
if (_screen != nil) {
  options.screen = _screen;
}

// BaseCarSceneDelegate.mm, in
// templateApplicationScene:didConnectInterfaceController:toWindow:
// — must precede the rootViewController assignment, which loads the view
self.navViewController = [[NavViewController alloc] init];
[self.navViewController setMapViewType:NAVIGATION];
[self.navViewController setScreen:window.screen];
self.navViewController.stateDelegate = self;

The phone NavigationView is unaffected — it never calls the setter and keeps the main-screen default.

I am running exactly this as a yarn patch. It compiles clean for x86_64 and arm64. I have not yet been able to confirm on a head unit whether it resolves the sizing, since I am waiting on a build — I will report back here either way. Happy to open a PR if the shape looks right to you.

React Native version

0.86.2

React version

19.2.3

Package version

0.16.3

Native SDK versions
  • I haven't changed the version of the native SDKs

(GoogleNavigation 10.13.0 / GoogleMaps 10.13.0, pinned via a config plugin for react-native-maps coexistence.)

Steps to reproduce
  1. Set up a CarPlay scene with BaseCarSceneDelegate as documented in CARPLAY.md.
  2. Override onSessionAttached to enable the navigation header and footer: 
    - (void)onSessionAttached {
  [self.navViewController setHeaderEnabled:YES];
  [self.navViewController setFooterEnabled:YES];
}
  3. Start a guidance session on the phone and connect to a CarPlay head unit.
  4. The header and footer render at phone scale; on a short display the header's lane-guidance dropdown overlaps the ETA footer.

Note this needs real CarPlay hardware — the CarPlay simulator currently crashes on iOS runtimes above 26.3 (#607).

Lenguaje dominante
TypeScript
Estrellas
226
Forks
39
Merge medio
1 d 20 h
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de googlemaps/react-native-navigation-sdk

Todos los issues de googlemaps/react-native-navigation-sdk

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.