#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 /…