• Actual behavior: whenever a path to a file contains "3.0x" it will be displayed as a xxhdpi (3x) high resolution image
• Expected behavior: must pay close attention to what the app developer specified in pubspec.yaml. Not doing so may compromise introducing other kinds of variants in the future.

Sample pubspec.yaml

. . .
  assets:
    - assets/3.0x/ic_accessibility_black_36dp.png 
    - assets/3.0x/yetAnotherFolder/hackyAsset.png

When loading such images with

new Image.asset('assets/3.0x/yetAnotherFolder/hackyAsset.png'),

or

 new Image.asset('assets/3.0x/ic_accessibility_black_36dp.png'),

• expected behavior: They should behave like mdpi (1x) images
• actual behavior: They behave like xxhdpi (3x) hi-res image

There are 2 pitfalls here. The obvious one is that path assets/3.0x/yetAnotherFolder doesn't comply with the specs that the main file sits on <folder> and the variant sits on <folder>/3.0x. The second is that the intention of the app developer may have been putting a mdpi (1x) file on assets/3.0x/ic_accessibility_black_36dp.png .

I like how smart it is, but a) this is clashing with what AssetManifest.json says. And b) I'm afraid that one day other types of variants (say screen size, localization...) will make pre-existing apps break because they'll start treating its main variant assets as non-main variants. In any case I can't be sure if this is a feature or a bug. I'd like to help document it properly if it's the former or fix it if it's the latter.

@tvolkert @Hixie @HansMuller