There is always some confusion regarding the proper way to handle different screen size on Android. The platform mechanism of defining resources using qualifiers that are resolved at runtime is clever, and quite powerful. But people are often tempted to use the infamous sw-XXXdp as a one-size-fits-all solution to have a proper "tablet" layout.

However, the "smallest-width" qualifier is misleading, and should (almost) never be used to take any layouting decision.

First of all, the way we define our layouts should never depend on concepts such as "phone", "tablet", "portrait" or "landscape". With multi-window (splitting the device screen in two sub-screens to have two apps running at the same time), these concepts lose their meaning. The only things that matter are the dimensions of the current Window.

Layouting decisions are (almost) always depending on either the width or the height of the Window. For instance, deciding if a list of elements should be shown as a single column, or as a grid with 2, 3 or 4 columns, this only depends on the width of the window. Larger horizontal margins? Width of the window. Having two buttons side-by-side or stacked one above the other? This one may depend on the height of the window.

These width/height decisions will use these qualifiers:

-wXXXdp
-hXXXdp

And what about smallest-width? (-swXXXdp)

The smallest width of the current Window is the smallest of the two width when this window is shown in portrait and in landscape. So it's not the smallest of the two dimensions of the Window. It's the smallest one when considering these two dimensions without considering standard screen decoration (status bar and navigation bar).

The best way to get it is with an exemple.

Consider this window. It may be a tablet in landscape orientation.

         1300dp
   ------------------
   |                |
   |                | 728dp
   |                |
   ------------------

This window has a smallest-width of 800dp. How can that be? To get this value, Android compares the width of the Window in this orientation (1300dp) with the width when switching the same Window in portrait. In portrait, the Window dimensions are not the same, since screen decoration always affect vertical dimensions (status bar and navigation bar are always at the top and bottom).

      800dp
   -----------
   |         |
   |         |
   |         | 1261dp
   |         |
   |         |
   -----------

The width in portait is 800dp. So in the end, the smallest-width of this Window is 800dp.

This clearly show the main problem of the smallest-width: It does not tell you anything about the dimensions of the current Window. It only tells that one of the two dimensions (you don't know which one) is greater than a specific size. And you have no idea about the other one.

For instance, these two Windows share the same smallest-width (728dp).

          1400dp                    750dp
   -------------------          ------------
   |                 |          |          |
   |                 | 728dp    |          | 728dp
   |                 |          |          |
   -------------------          ------------

Same with these two (411dp):

     411dp              411dp
    --------           --------
    |      |  230dp    |      |
    --------           |      | 800dp
                       |      |
                       |      |
                       --------

With these exemples, it's easy to understand that there is no way to rely on this value to take any layouting decision that would be appropriate for the current Window.

And no, relying on the device orientation would not be helpful here. These Windows can all be created without changing the orientation, with the resizing capabilities of Android, especially on ChromeOS (Windows can be resized to almost any size).

TL;DR

Never take any layouting decision using the smallest-width qualifier, nor the orientation one. Only consider the dimension that will impact the layouting decision (either width or height), and use the appropriate wXXXdp or hXXXdp accordingly.