Эмулятор Android сообщает 600×1024 MDPI как XLarge?

#android #emulation #resolution #kindle-fire

#Android #эмуляция #разрешение #разжечь огонь

Вопрос:

В настоящее время я пытаюсь протестировать существующее приложение на совместимость с скоро выпущенным планшетом Amazon Kindle Fire. Говорят, чтобы установить эмулятор на 600×1024, а плотность ЖК-дисплея — на 169 (https://developer.amazon.com/help/faq.html?ref_=pe_132830_21362890#KindleFire хотя в электронном письме они сказали 160 вместо 169) и что он должен сообщать как «большой», а не «xlarge» (это я получил из обмена сообщениями по электронной почте с их службой поддержки, где я жалуюсьэто не работает).

Google, похоже, поддерживает это как истинное в своем разделе о тестировании для нескольких размеров экрана, когда они указывают это разрешение и MDPI как «большие» (http://developer.android.com/guide/practices/screens_support.html#testing ). Однако всякий раз, когда я включаю папку «layout-xlarge» вместе с «layout-large», эмулятор всегда загружает «xlarge». Если я изменю плотность ЖК-дисплея на что-то вроде 240, он загрузит «large» вместо «xlarge», но это не должно быть правильным, и я беспокоюсь, что это означает, что он не будет работать на конечном устройстве. Чтобы проверить это, я взял образец API-10 «Multi-Res» и создал серию папок макета, описанных выше, и каждый раз, когда он загружал «xlarge», если он был там, и загружал «large», если не было «xlarge».

Итак, мой вопрос в том, правильно ли я читаю документацию или мой эмулятор каким-то образом испорчен, поскольку люди из Amazon настаивают на том, что он должен сообщать как «большой», что, если бы это было правдой, он никогда не загрузил бы «xlarge», верно?

Вот что у меня есть в манифесте в примере Multi-Res, который я изменил, чтобы проверить это:

 <?xml version="1.0" encoding="utf-8"?>
<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.android.multires"
  android:versionCode="1"
  android:versionName="1.0">

  <uses-permission
    android:name="android.permission.INTERNET"/>

  <application
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name">

    <activity
      android:name=".MultiRes"
      android:label="@string/app_name">
      <intent-filter>
        <action
          android:name="android.intent.action.MAIN"/>
        <category
          android:name="android.intent.category.LAUNCHER"/>
      </intent-filter>
    </activity>
  </application>

  <uses-sdk android:minSdkVersion="4" />

  <supports-screens android:anyDensity="true"
                    android:xlargeScreens="true"
                    android:largeScreens="true"
                    android:normalScreens="true"
                    android:smallScreens="true" />

</manifest>
  

Комментарии:

1. Для чего это стоит (на мой взгляд, не так много, поскольку это хак), в последнем ответе, который я получил от Amazon, говорится: To override the configuration you would have to do the following in your activity onCreate method (before you load layouts or anything else). final Configuration config = new Configuration(context.getResources().getConfiguration()); config.screenLayout = (config.screenLayout amp; Configuration.SCREENLAYOUT_LONG_MASK) Configuration.SCREENLAYOUT_SIZE_LARGE; context.getResources().updateConfiguration(context.getResources().getConfiguration(), context.getResources().getDisplayMetrics());

2. Возникла та же проблема, за исключением того, что это решение, похоже, не работает — Android считывает данные из значений-xlarge, а не значений-large.

Ответ №1:

Похоже, это ошибка в документации. Если мы посмотрим на фактический код, который используется для вычисления размера экрана, мы увидим, что экран 600×1024 с разрешением 160 точек на дюйм действительно будет считаться xlarge.

Не верьте мне на слово. Реализация находится в WindowManagerService.computeNewConfigurationLocked() (предупреждение о медленном JavaScript). Интересные моменты заключаются в следующем. Размер экрана в пикселях масштабируется в зависимости от плотности:

     longSize = (int)(longSize/dm.density);
    shortSize = (int)(shortSize/dm.density);
  

Для экрана с разрешением mdpi (160 точек на дюйм) dm.плотность будет 1,0. Для hdpi (240 точек на дюйм) это будет 1,5. В нашем случае у нас есть экран mdpi. Итак, после выполнения этого кода longSize == 1024 и shortSize == 600 . Вскоре после этого мы получаем этот код:

     // What size is this screen screen?
    if (longSize >= 800 amp;amp; shortSize >= 600) {
        // SVGA or larger screens at medium density are the point
        // at which we consider it to be an extra large screen.
        mScreenLayout = Configuration.SCREENLAYOUT_SIZE_XLARGE;
    } else if ( // ...
  

что с нашими значениями longSize и shortSize означает, что mScreenLayout будет присвоено Configuration.SCREENLAYOUT_SIZE_XLARGE , другими словами, экран будет считаться «xlarge» . Интересно отметить, что если бы экран был на один пиксель меньше с короткой стороны, он считался бы только «большим».

Итак, вы правильно читаете документацию, но, насколько я вижу, документация неверна, и ваш эмулятор в порядке.

Комментарии:

1. Спасибо, Мартин. Amazon настаивает на том, что он большой, но, возможно, это означает, что они изменили этот же код.

2. Чтобы добавить к этому больше, теперь, когда у меня действительно есть Kindle Fire, я могу подтвердить, что он действительно представляет себя как «Большой», А НЕ «XLarge», как это делает эмулятор. Разработчик остерегается.

3. Документация на самом деле правильная, но в ней не упоминается, что она применима только к Honeycomb 3.1 и более поздним версиям. Посмотрите этот коммит , который был сделан вскоре после выпуска Honeycomb 3.0.

4. Я управляю ресурсами Kindle Fire, используя суффикс -large-mdpi-1024×600 для папок ресурсов, но обращаю внимание на устройства с аналогичным форм-фактором и экраном, например Galaxy Tab 7 » — rainbowbreeze.it/screen-density-del-kindle-fire-e-galaxy-tab

5. @Rainbowbreeze, что 1204×600 часть каталога layout выглядит неправильно. Вы уверены, что это правильно? developer.android.com/guide/topics/resources /…