Question about SVG launcher icons and scaling

I'm using an SVG for my launcher icon, specified like this in drawables.xml:

<drawables xmlns:xsi="">www.w3.org/.../XMLSchema-instance" xsi:noNamespaceSchemaLocation="">developer.garmin.com/.../resources.xsd">
    <bitmap id="LauncherIcon" filename="my_icon.svg" dithering="none" />
</drawables>

However, when I build, I get the following warning:

WARNING: epix2pro47mm: The launcher icon (192x192) isn't compatible with the specified launcher icon size of the device 'epix2pro47mm' (60x60). The image will be scaled to the target size.

Is there a way to define an SVG launcher icon and have it automatically scaled correctly for each device, without needing to create a separate drawables.xml with device-specific sizes?

Thanks for any advice!

Top Replies

  • I mean, the icon is already being auto scaled for every device in the manifest, right? I think the actual objection here is that there's a warning about it. (To be fair, you are not alone…

All Replies

  • Is there a way to define an SVG launcher icon and have it automatically scaled correctly for each device, without needing to create a separate drawables.xml with device-specific sizes?

    I mean, the icon is already being auto scaled for every device in the manifest, right? I think the actual objection here is that there's a warning about it. (To be fair, you are not alone here - most devs find this annoying.)

    Playing devil's advocate, I can think of a couple of reasons Garmin would want to warn about this:

    - to cover the cases where scaling would possibly produce an image that doesn't look good (e.g. when a raster image is scaled)

    - to cover the case where the aspect ratio of the image is different from the aspect ratio of the target launcher icon size: in this case, the compiler would have to distort the image (scale x/y differently), crop the image, or shrink the image to fit (should the original image be centred in the "canvas", placed at the top-left, or somewhere else?). There's probably not one approach that would work perfectly for every possible image

    (Note that a tiny minority of devices have a non-square launcher icon, while most devices have a square launcher icon, meaning there's no way to provide a single launcher icon with the correct aspect ratio for *all* devices. Yes, I realize that no dev is obligated to build for all devices, or that it's always an option to provide alternate launcher icons for the oddball devices with non-square launcher icons )

    What's too bad is there isn't really a way to easily see the result of the auto scaling. You'd either have to decompile the PRG file (there is a decompiler on github, but think it just gives you a text description of every section), or sideload the app on a real device and look at the icon (the on-device Connect IQ store shows the launcher icon for every app type.)

  • I wish the simulator would display the launcher I on for a split second when the app is starting.

    What I do to check the launcher icon is to display it in a regular view. In some of my apps I really display it in some place, in others I just added some view to check if there isn't something obviously wrong with the launcher icon and then removed the view.

    However there is something that can't be checked in the simulator: you don't know on which device the background in the activities/apps list is white / black. I think this should be documented. 

  • However there is something that can't be checked in the simulator: you don't know on which device the background in the activities/apps list is white / black. I think this should be documented. 

    We already talked about this, but on some devices (like FR935), the activities/app list background is context sensitive. e.g. on FR935, the background for the favourites list is white, but the background for the non-favourites list is black. I *think* even older watches (like Fenix 3?) allowed you to set a system-wide background colour (black or white) which affected things like settings menus - not sure if the apps/activities list would also be affected.

    The other thing is that this kind of thing is subject to change. It's a rare example, but FR945LTE was launched with an older UI (similar to FR945) but later received an update to make it more like FR955. Ofc it's a moot point now that you can't build an app for older FR945 firmware versions, but one point this could have been an issue. (I don't know if one of the changes between the old and new UI was the background colour for the activities/app list, it's just an example of how it could've changed for a given device over time.)

    I don't think devs have much choice except to design launcher icons that look good on either a white or black background. Either that or only design for currently supported AMOLED devices (like FR965), where you can be reasonably sure the background will almost always be black. Some (or all?) of the currently supported MIP devices (like FR955) share the same behaviour as their AMOLED cousins, too (probably because they share the same base code for their firmware).

    When we last talked about this, I previously shared an example of an icon whose border/outline was a white line surrounded by black lines (or vice versa), so it looked ok whether or not the background was black or white (the border would be visible either way).

    If Garmin really wanted to make things "nice" for devs, they could've allowed devs to submit two versions of every launcher icon: one for white backgrounds and one for black backgrounds.

    Kinda like how iOS supports dark icons now (distinct from overall dark mode), and devs basically have to opt-in by providing an alternate dark version of their app icons (usually white elements replaced by grey/black elements). Ofc it's not exactly the same thing, as this is actually a different theme, which goes beyond just making the icons look good against a certain background. But it is an example of a system where an app can have different icons for different contexts.

  • Another example of something that can't be checked in the sim: whether a device's built-in data fields use title case for labels (e.g. "Avg Pace") or all-uppercase (e.g. "AVG PACE"). Sure, I can assume (for now) that all currently supported devices are all-uppercase, but it's harder to tell for older devices. I actually went through a bunch of DCR reviews and looked at screenshots to try to figure out which devices used the older title case scheme.

    Ofc it's well-known that it's hard to make complex data fields look just like the built-in fields, and even simple data fields have their problems (years of bugs with value text that's displayed too small for the field.)

    I guess my point is Garmin doesn't really care about making it easy for CIQ apps to blend in with native stuff and/or to look as good as possible.

  • If you want to see what the launcher_icon looks like in the sim, an easy way to do that is create an ultra simple test app with little more than a glance view,  When you run it in the sim, you see the glance and the icon is also displayed.  And you can easily just change the icon do see how different ones look.

    But, the sim may also be a bit deceptive as things like this are displayed by pixel and not actual display size.  So if the real display on a device that's 360x360 is the same as a device that 454x454, the icon might not look the same in the sim  for the 454x454 device as on the real device

  • I mean, the icon is already being auto scaled for every device in the manifest, right? I think the actual objection here is that there's a warning about it. (To be fair, you are not alone here - most devs find this annoying.)

    The warning is one concern. Beyond that, with the current default behavior, it's unclear whether the SVG is first converted into a large bitmap and then scaled down, or if a correctly sized bitmap is generated directly from the SVG. Naturally, the latter would be preferable.

  • I agree, and if you really care, then you should either generate the launcher icons by yourself for each size, or you could try it somehow by creating an svg that somehow can be tested against the above theory...

  • Yes, already created separate drawables.xml for each launcher icon size.

    it will also be interesting to see how well the SVG to bitmap coversion works. In my other app I use a script generating PNGs via Inkscape, and I really like the anti-aliasing.

  • I guess you can also popup a notification since 5.1.0 with the launcher icon as default.

  • Don't be fooled by the nice, antialiased png! Depending on the device you might only have 64 or 8 colors, so it'll be changed by the compiler again.