Мы с Сашей, наконец, выпустили прошивку для нука!

И в связи с этим посты:

mynook.ru:
http://mynook.ru/rusificirovannaya-proshivka-dlya-nook/
Habrahabr:
http://habrahabr.ru/blogs/ebooks/97653/
http://habrahabr.ru/blogs/android/97666/
the-ebook.org:
http://www.the-ebook.org/forum/viewtopic.php?t=14522

1) удаляем старую библиотеку от nookdevs:

adb uninstall com.nookdevs.library

2) скачиваем билды FBReader’а и My Books

3) кладем их к adb (Android Debug Bridge)

4) устанавливаем:

adb install fbreaderj-nook-065.apk

adb install nooklibrary-fb2.apk

Собственно, все!)
Наслаждайтесь альфа-версией)

Особенности

• Другая анимация - сделано на подобии того, как было в 1.0. Происходит постоянная диффузная смена двух картинок.
• Возможность смены без перекомпиляции кода
• Простота создания анимации
• Сделан белый фон
• Для нормальной работы картинки должны быть одинаковых размеров
• Картинки центрируются

Видео

Что нам необходимо:

• Две картинки boot-logo-1.png и boot-logo-2.png. Причем размер каждой стороны должен быть равен степени двойки. Например: 1 и 2
• Измененный bootanimation
• adb

Бэкап

Для начала необходимо выполнить такой код, что бы сохранить оригинальную анимацию

adb pull /system/bin/bootanimation bootanimation_backup

Установка

1. Загрузка bootanimation в устройство:

   adb push bootanimation /system/bin/bootanimation
   

2. Установка прав bootanimation:

   adb shell
   cd /system/bin
   chmod 777 bootanimation
   

3. Загрузка изображений в устройство:

   adb push boot-logo-1.png /system/media/boot-logo-1.png
   adb push boot-logo-2.png /system/media/boot-logo-2.png
   

На данный момент все юниты умеют ходить) однако необходимы некоторые маленькие заключительные штрихи и исправление подергивания на финише, необходим правильный алгоритм просчета скоростей. Все юниты, перемещения которых прописаны в виде скрипта ходят так, как нужно.

Атака юнитов

Необходимо доделать код для орудий, которые выпускают что-то в направлении противника, т.е. Ракеты, Лазеры и тпх, а не просто появляются в виде вспышек на противнике, а так же другие виды оружия, которые, правда, я еще не видел) И на этом все будет закончено с оружием для данного этапа.

Здания

Здесь почти ничего не делалось, просто было проверено, что все правильно рисуется и тпх, однако для зданий и так мало что можно сделать)

Что дальше?

Сейчас я некоторое время повожусь с юнитами, подшлифую все, что бы не крашилось и буду делать строительство зданий.

• Добавлен UI из оригинальной игры
• Сделана подгрузка карты
• Сделаны карты путей
• Скроллинг более-менее плавный теперь
• Реорганизация движка

Скриншоты

Дистрибутив

Скачать APK вы всегда можете на google-code

Зачем?

Что нам это дает:

• Возможность установки прошивок Hero
• Оптимизация работы некоторык кастомных прошивок (CyanogenMod, к примеру)
• Возможность использования App2SD

Материалы

• HTC G1 с рековери - CyanogenRecovery v1.4 (xda-developers thread, cm-recovery-1.4.img)
• SDCard - рекомендуются карты шестого класса, т.к. они обеспечивают нужную производительность
• Рутованная прошивка с поджержкой ext3/ext4 и swap’ом. Рекомендуется  CyanogenMod.
• [Опционально]Android Debug Bridge tool (adb) можно взять из последнего SDK. Информация по работе с adb на xda-developers.
• Прямые руки

Подготовка SD-карты

1. Загрузитесь в recovery(home + power)
2. Откройте консоль. (По желанию подключитесь к консоли с компьютера через adb коммандой adb shell)
3. Откройте гнушную утилиту parted для sd-карты: parted /dev/block/mmcblk0 (на конце - ноль)
4. Напишите print для получения информации о разделах sd-карты
5. Вы получите сообщения вида:

   Model: Unknown (unknown)
   Disk /dev/block/mmcblk0: 7969MB
   Sector size (logical/physical): 512B/512B
   Partition Table: msdos
   
   Number  Start   End     Size    Type     File system  Flags
    1      512B    7469MB  7469MB  primary  fat32        lba
    2      7469MB  7969MB  500MB   primary  ext2
   

   или если карточка новая:

   Model: Unknown (unknown)
   Disk /dev/block/mmcblk0: 7969MB
   Sector size (logical/physical): 512B/512B
   Partition Table: msdos
   
   Number  Start   End     Size    Type     File system  Flags
   

6. Теперь нам необходимо удалить все разделы командой вида rm <номер раздела>. В нашем случае:

   rm 1
   rm 2
   

Подсчет размеров разделов

1. Для swap-раздела выделим 32MB. Остается: 7969MB - 32MB = 7937MB
2. Для ext2/3/4 раздела выделим 500MB. Остается: 7937MB - 500MB = 7437MB
3. Итого для FAT32 раздела осталось - 7437MB

Создание разделов

1. Для нормального функционирования App2SD и swap’а необходимо создать разделы в следующем порядке: fat32, ext3, linux-swap. Для создания разделов используется комманда: mkpartfs <тип раздела> <тип файловой системы> <начало> <конец>, где начало и конец означают положения начала и конца раздела, если написано число, то по-умолчанию это мегабайты, для уточнения можно в конце приписать B или GB.
2. В нашем случае необходимы следующие команды:

   mkpartfs primary fat32 0 7437
   mkpartfs primary ext2 7437 7937
   mkpartfs primary linux-swap 7937 7969
   

3. Можете вызвать print для проверки конфигурации разделов. Все закончено - можете выйти из приложения командой quit. (не обращайте внимание на сообщение, появляющееся перед выходом)

Апгрейд ext2 до ext3 или ext4

• Для апгрейда до ext3 выполните команду - upgrade_fs
• После апгрейда до ext3 можно выполнить апгрейд до ext4 командой:
  tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p2
  e2fsck -fpDC0 /dev/block/mmcblk0p2

Каждое приложение должно иметь файл AndroidManifest.xml (именно с таким именем) в его корневой папке. Манифест содержит информацию о приложении для ОС Android, эта информация необходима системе прежде чем она запустит какой-либо код на исполнение. Среди прочих вещей, манифест делает следующие вещи:

• Он содержит название пакета Java. Это имя является уникальным идентификатором для приложения.
• Он описывает компоненты приложения - activities, services, broadcast receivers, и content providers, из которых состоит приложение. Оно содержит имена для классов, которые описывают каждый компонент и описывает условия их использования (к примеру, какие сообщения интент может принимать). Эти описания предоставляют информацию ОС Android о компонентах приложения и о условиях их выполнения.
• Он определяет какие процессы будут обрабатывать компоненты приложения
• Он описывает разрешения(permissions), которые необходимы приложению для работы с защищенными частями API и с другими приложениями.
• А так же содержит разрешения(permissions), которые необходимы для связи с компонентами системы.
• Содержит списки классов, используемых для профилирования и для получения другой информации о приложении во время исполнения. Эти описания присутствуют только при разработке и тестировании. Перед публикацией они удаляются из манифеста.
• Он описывает минимальный уровень Android API, необходимый для приложения
• Он содержит список библиотек, с которыми приложение должно быть слинковано

Структура файла

Диаграмма, показанная ниже, описывает основную структуру файла манифеста и каждый элемент, который он может в себе содержать.

<?xml version="1.0" encoding="utf-8"?>

<manifest>

 <uses-permission />
<permission />
<permission-tree />
<permission-group />

 <instrumentation />

 <uses-sdk />

 <application>

 <activity>
 <intent-filter>
 <action />
 <category />
 <data />
 </intent-filter>
 <meta-data />
 </activity>

 <activity-alias>
 <intent-filter> . . . </intent-filter>
 <meta-data />
 </activity-alias>

 <service>
 <intent-filter> . . . </intent-filter>
 <meta-data/>
 </service>

 <receiver>
 <intent-filter> . . . </intent-filter>
 <meta-data />
 </receiver>
<provider>
 <grant-uri-permission />
 <meta-data />
 </provider>

 <uses-library />
 <uses-configuration />  

 </application>

</manifest>

Правила для файла

• Обязательны только  <manifest> и <application> элементы
• Все параметры передаются только через атрибуты
• Только элементы - между тегов не может быть обычного текста
• Порядок элементов не важен. Единственное исключение <application-alias> должен следовать за соответствующим <application>
• Формально аттрибуты не обязательно, но многие элементы имеют обязательные параметры. Смотрите документацию
• Все, кроме <manifest>, имеют перед параметры, начинающиеся с “android:"
• Имена классов почти всегда пишутся полностью с именем пакета, ислючение - классы в пакете, который указан в манифесте - их просто можно начинать с точки
• Имена ресурсов пишутся так: @[package:]type/name, для тем - ?[package:]type/name

Возможности Манифеста

Intent Filters

Интенты - основа метода вызова компонентов приложения. Интент - это некий набор данных. Содержит себе название действия, некоторые его параметры, а так же еще некоторые инструкции.

Система получает интент, создает экземпляр объекта (если нужно), а потом передает в этот объект этот интент.

Для того, что бы компонент мог принять интент существуют intent-filters и они описываются в манифесте тегом <intent-filter>, в котором можно задать условия принятия интента.

Иконки и Текст

Некоторые элементы содержат поля icon, label и description.

К примеру, в permission’е все эти три поля есть. Эти три поля используются тогда, когда необходимо предоставить разрешение приложению и пользователю показываются необходимая иконка и текст.

Permissions

Permission - это способ получить доступ к закрытой части API. Эта защита существует для защиты пользователя от приложения.

Для того, что бы показать, что приложение использует Permission необходимо прописать тег. Эти Permissions показываются, к примеру, при установке приложения.

У приложения могут быть свои компоненты с разрешениями для их использования - они задаются через тег ]]> http://stepa.name/archives/267/feed http://stepa.name/archives/217 http://stepa.name/archives/217#comments Thu, 28 May 2009 18:07:56 +0000 HotHeart http://stepa.name/?p=217 В данный раз внешних изменений почти нет.

• Пока что выключена карта, поскольку съедает много памяти
• Отрисовка GRP-изображений была переделана - теперь есть два рендера: первый рисует, на лету преобразуя индексы цветов в массив цветов, а затем уже рисует, второй же сразу все кеширует в битмапы. Скорость отрисовки во втором случае больше в разы, но в первом случае памяти в два раза меньше потребляется
• Сделан полный рефакторинг кода. Добавлено наследование. Отказ от него из-за маленькой скорости - было глупостью, ибо она усложняла сильно код и не позволяла писать сопровождаемый код.
• Все полностью перенесено на SDK 1.5
• Добавлено управление на экране

Что дальше? необходимо по-прежнему улучшать код графической части - необходима разработка хорошего алгоритма для кеширования графики, поскольку производительность андроида оставляет желать лучшего.