Обзор особенностей ядра Андроида

[Mairon]

править код Андроида, не будучи сотрудником Google, практически невозможно

Не совсем верно. Думаю, что вернее фраза править код Андроида, не будучи сотрудником компании, входящей в Open Handset Alliance, практически невозможно.

Вот, например, первый попавшийся свежий коммит сотрудника Intel в master branch Android.

Статья хорошая, пишите ещё, а то популярных статей по архитектуре Android можно по пальцам пересчитать, да и редко от одного автора, из-за чего получается, что кто в лес, кто по дрова.

[lol2Fast4U]

Править код никто не мешает никому. Патчи от кого попало в AOSP может и не возьмут, а в CyanogenMod, например — запросто.

[HighFlyer]

Да, про код совсем неясно высказался :)

[xEzhik]

Очень занимательно. С нетерпением жду продолжения, про остальные составляющие системы.

[zyrik]

Во-первых, меня не покидает ощущение, что я уже где-то это читал. Я бы всё-таки советовал давать ссылки на источники. В данном случае, мне кажется, что это книга Karim Yaghmour «Embedded Android» и презентации Marakana group (сейчас их можно найти здесь).

А во-вторых, несотрудники Google тоже имеют право отправлять свои патчи. Если они пройдут ревью, то их включат в основную ветку.

[HighFlyer]

Абсолютно верно: отмеченные два источника являлись основными. Надо дописать список литературы.

[olegy]

Спасибо, жду продолжения

[iAHTOH]

Разработчики Андроида даже не пытались найти общее решение “на будущее”, которое потом без проблем бы вливалось в основное ядро, не консультировались по этой проблеме с сообществом ядра Линукс. Можно ли их за это винить?

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

Спасибо за статью! Жду продолжения!

[I_Am_Hated]

Если данная тема будет интересна, в следующих статьях мы рассмотрим и их.
Тема очень интересная.

Если кто посоветует интересные документы по Дальвику или в какой книге про Дальвик достаточно глубоко копают, то был бы очень признателен. На Хабре про него все перечитал, листал книги по Андройду, но там подача материала в научно-популярном стиле и очень мало по архитектуре Дальвика.

[zyrik]

Тема довольно интересная и не такая уж и простая :) Я бы посоветовал начать вот отсюда, а дальше лучшее, что я нашел в свое время, это вот это. А вообще, лучше всего читать исходники, но, к сожалению, это делать довольно сложно (возможно только мне).

[I_Am_Hated]

Спасибо, добрый человек!

[xyyx]

Boinic (реализация libc)

Скорее имелось в виду: Bionic

[seleko]

Wakelocks-то да, отличная хрень. Особенно учитывая их неуправляемость штатными средствами.

[viacheslav_dev]

Вот таких вот статей и не хватает. Большое спасибо. Пишите ещё!

[POPSuL]

Mail.ru становится тортом!
Статья отличная, продолжайте в том же духе! :)

[AlexanderG]

LocationManager делегирует вызов прокси-объекту, преобразующему Java-методы и объекты в Binder-транзакцию (прокси-объектом у LocationManager-а является mService).

Можно пару слов о том, как это происходит? Что из себя структурно представляет Binder-транзакция, и в каком виде там существуют Java-объекты? Не возникает ли тормозов/расхода батареи из-за такой сложной логики взаимодействия?

[HighFlyer]

Наглядно на то, что происходит, можно в любых классах Proxy и Stub, которые создаёт утилита aidl.

Java объекты перегоняются в обычный байтовый массив на стороне клиента (средствами Parcel-а и Parcelable-а), из которого вновь формируются объекты на стороне сервиса.

Здесь есть описание структуры транзакции. Помимо аргументов вызываемого метода (data.ptr.buffer), содержит идентификатор метода, который необходимо вызвать (code), идентификатор сервиса, в который всем этим данным надо отправиться (target.handle), и другие поля.

Все операции простые и быстрые (записать в массив — прочитать из массива), накладные расходы, конечно, есть, но вряд ли соизмеримы со стоимостью выполнения самой логики вызываемых методов. Сам замеров не делал :) Что-то похожее надо делать при любом межпроцессном взаимодейтсвии: «как есть» Java-объекты из одной виртуальной машины в другую не передать.