If you use pixel units for drawing your UI, you have essentially two alternatives:
(1) Leave it to developers to make sure that their code correctly handles different DPIs. This results in every app having to produce its own solution for some very difficult problems, such as those ridiculous_fish mentions elsewhere in the thread, or else look terrible on some devices. (Yes, some of this can be encapsulated in libraries, but you'll virtually always do some custom drawing that requires manual handling.)
(2) Virtualize the pixels, so that depending on the DPI of the screen you're displaying on, a "pixel" does not necessarily correspond to a single device pixel.
Generally what happens is that you try #1, realize that many or most developers screwed it up, and shift to #2.
See CSS "pixels" for an example of this phenomenon.
No, there's actually a 3rd solution which is what Android uses:
(3) Expose both pixels and dips. Both are first-class units in Android. The 2D drawing API works exclusively in pixels, but the layout commonly works in DIPs instead.
Developers then do their layouts in dips but custom 2D drawing in pixels. Or really most anything in code is using pixels, dips are largely contained in the XML layout files.
(1) Leave it to developers to make sure that their code correctly handles different DPIs. This results in every app having to produce its own solution for some very difficult problems, such as those ridiculous_fish mentions elsewhere in the thread, or else look terrible on some devices. (Yes, some of this can be encapsulated in libraries, but you'll virtually always do some custom drawing that requires manual handling.)
(2) Virtualize the pixels, so that depending on the DPI of the screen you're displaying on, a "pixel" does not necessarily correspond to a single device pixel.
Generally what happens is that you try #1, realize that many or most developers screwed it up, and shift to #2.
See CSS "pixels" for an example of this phenomenon.