Are there any official guidelines for how many pixels the edge radii should be when giving Android launcher icons rounded corners?
I've found guidelines for launcher icon pixel sizes (but rounded corners aren't mentioned), a tool called Android Asset Studio which rounds the corners for you (but the tool provides undesirable and non-configurable padding around the edges of each icon), and another tool called Icon Slayer (but the tool creates corners that I feel are way too round, and feel very iOS).
I've also noticed that of all the apps that I personally use that have rounded corners on their launcher icons, the edge radii almost always seem to vary from icon to icon. When I place the various icons next to each other, some look pretty close, but they mostly feel just a little bit off from each other.
Any help?
Check out Google's official Material Design guidelines for Icons about two thirds of the way down the page under the sub-heading Corners.
It indicates you should use a 2px radius on the corners. If go up a few sections, under the heading Content Area you'll see this is for a 24x24 px icon. You can scale up for other resolutions from there.
The radius of the corners should be 8.33% of the size of the icon according to Materiel guidelines.
So if the size of the icon in your project is:
1000px by 1000px, then the corner radius should be 83.3px.
However, you should probably make your document bigger than that.
Maybe 2000px by 2000px, and the radius:
2000px * 0.0833 = 166.6px
This is just in case you need to export a version of your icon that is bigger than 1k px.
Squares and rectangles on 192x192 px grid, when used as background shapes for android product icon, should always have 12px radius corners.
Read details
Related
I want splash screen icon in Rectangle shape instead of rounded shape in android 12
I don't believe you can. If you look at point 3 here: https://developer.android.com/about/versions/12/features/splash-screen#elements
It describes the image "As with adaptive icons, ⅓ of the foreground is masked"
The shape of the icon shown is just whatever shape is being used by the system for adaptive icons.
The splash screen changes in android 12 are specifically to reduce the amount of customisation you can do on splash screens, to keep the UX more consistent between apps. The customisation options that do exist are detailed on that page too.
Make your logo's canvas around 35% bigger, with the square logo in the middle, keeping the logo the same size. Then Android 12 will round a 1/3rd of the image, but your logo will be untouched.
I am trying hard to get rid of the extra margin around the ic launcher icons generated by Android Studio without luck. I know this is one of Google's material design trends. Though, the icons are so small on devices which is ugly.
I have Googled for around three hours and the only workaround I could find is to generate the clipart with a transparent background and photoshop the background with rounded corners which is pretty slow.
Is there a better solution than this?
Thank you.
Per the Designing adaptive icons blog post, the adaptive icon images created in the drawable directory for use on API 26+ devices follow the adaptive icon size and shape:
You'll note that while the entire image must be 108dp by 108dp, the actual visual area is only the center 72dp - the outer edge is only seen when dragging the icons around (where parallax effects may cause it be visible).
The Pixel Launcher, as well as many third party launchers, enforce the use of adaptive icons on API 26+ devices, so you should always design with that requirement in mind - the alternative, in the Pixel Launcher's case for instance, is to place your non-adaptive icon within a white circle.
Therefore you should always design your icon such that the background layer takes up the full size, but any foreground image you put on top of that background layer should be contained within that center area.
You can't just remove that margin without the foreground image being messed up, but as per the Implementing Adaptive Icons follow up blog post, you can remove any white excess around the foreground by putting your trimmed image within a transparent drawable of 108dp x 108dp by using an InsetDrawable.
<!-- Center a 54x54dp image in the 108x108dp size of adaptive icons -->
<inset
android:drawable="#mipmap/ic_fg_trimmed"
android:insetLeft="25%"
android:insetTop="25%"
android:insetRight="25%"
android:insetBottom="25%" />
Although this would have to be something you'd need to do to the ic_launcher_foreground image yourself after the fact.
A better solution, in most cases, is to use vector drawable images as the input to the Android Studio Image Asset wizard - this will ensure they are always the right size and don't take up any additional space in your APK.
I think i had the same problem as you. I solved this with a nasty hack, in the AndroidManifest.xml I just changed the roundIcon to point to the standard icon.
<application
…
android:icon="#mipmap/ic_launcher"
android:roundIcon="#mipmap/ic_launcher"
See more from the docs.
I have a 9-patch that goes like this:
I'm using it as a background for a rectangular area in an Android app. I expect that the center pixel takes the majority of the area, the pixel right above is scaled to a one pixel thick horizontal line underneath the frame, the one to the left forms a one pixel thick vertical line, and so forth. All the 9-patch guides state that.
However, users are reporting color artifacts on display, as if those pixels are scaled in the other direction, too:
What am I missing?
I am using http://romannurik.github.io/AndroidAssetStudio/nine-patches.html to create a 9Patch image which is attached. . I use this is to set a drawableBottom to the TextView.But this does not stretch to the width the text view. What am i doing wrong ? This is the original image
Here are a few reasons for it to "not stretch"
Guides must only be one pixel wide, so if you want a 48×48 button, your png will actually be 50×50. Anything thicker than one pixel will remain part of your image.
guides must be solid black (#000000). Even a slight difference in color (#000001) or alpha will cause it to fail
MOST IMPORTANT: you should keep in mind that remaining area of the one-pixel outline must be completely transparent. This includes the four corners of the image – those should always be clear. This can be a bigger problem than you realize. For example, if you scale an image in Photoshop it will add anti-aliased pixels which may include almost-invisible pixels which will also cause it to fail*. If you must scale in Photoshop, use the Nearest Neighbor setting in the Resample Image pulldown menu (at the bottom of the Image Size pop-up menu) to keep sharp edges on your guides.
http://radleymarx.com/blog/simple-guide-to-9-patch/
You need to use android sdk draw9patch tool to make a 9-patch image.
you will need to define stretchable patches to image border like shown in below image border.
Consider the above image.
- The dotted line demarcates the 9-Patch png I will slice out of a photoshop file. I need it to create a popup box.
- The box incorporates a dropShadow as shown by the measuring tool in this photo.
- The pink lines are there to show how I will use the draw9Patch tool to create the 9-Patch.
My question is: If I have a View "Container" with the 9-Patch for a background I need to ensure its children views are always inside the white box. I was going to use padding for this. I was going to set the padding to equal the measuring tool. So if it is 30px in photoshop I'll set layout_paddingLeft"=30dp" for the container. (The design is at MDPI so I assume this conversion is okay). However how do screens of different densities handle the 9path. For instance will the measured area be 30px or 30dip ?
Via the draw9patch tool you can define:
vertical stretching: the black pixels on the left side
horizontal stretching: the black pixels on the top side
vertical content: the black pixels on the right side
horizontal content: the black pixels on the bottom
Note that stretching pixels don't have to be contiguous, so you can exclude some specific slice from stretching (look at the popup arrow above). At he same time you can make a reasonable idea of where your content will be placed just taking a look at the preview on the right, with the violet areas in. As you can suppose, this way you don't have to specify any padding in your layout: the view will take into account those values using the 9patch you set as background.
The no-stretching areas scale with the pixel density. So, if you set the 9patch above as an mdpi asset, the top-leftmost slice is rendered in a 50x40 pixels area #mdpi, and in 100x80 pixels area #xhdpi. The leftmost stretching areas instead arrange their width according to dpi, while height is arranged according to content. Other stretching slices work in similar way.
In both cases, dealing with a "low resolution" 9patch can lead to ugly pixelation artifacts. A possible solution is to provide a different 9patch for each supported dpi, or to define only the higher ones (xhdpi) and let Android scale them down accordingly.
The content bounds are handled as dp too, so they scale according to pixel density. For example: a left padding defined in the original 9patch as 40px#mdpi, will be translated in 80px#xhdpi, so the content will never flow out the given bounds. Note you can even override the content bounds specified in 9patch via the padding* properties in your layout.