Cześć @Grzegorz_Sterniczuk Hej @Stravi
Na początek niestety zła wiadomość 
Nie możemy udostępnić źródeł kernela, to wymaga podpisania NDA z Amlogic i uzyskania u nich dostępu. Wg nas jest to chyba co najmniej naciąganie GPL… ale taka jest niestety rzeczywistość. Tak robią wszyscy producenci SoC (Allwiner i inni też). Albo nie dostarczają w ogóle jądra (Linux / Android) lub źródła u-boot, albo dostarczając drzewa z gotowymi plikami binarnymi i bez pasującego kodu źródłowego. Albo stary kod bez łatek i kompletnego toolchain, zbudowanie jądra będzie trwało miesiącami a w konsekwencji i tak nie zadziała prawidłowo.
Czyli producenci SoC, niby udostępniają źródła (żeby nie być pozwanym o naruszenie GPL) ale w rzeczywistości migają się jak mogą i nie ułatwiają życia tym co chcieli by to zrobić.
My w DEV1/BT/2 używamy skompilowane jądro które mamy od Amlogic i które jest stabilnie, nie mamy w planie dodawać do niego żadnych sterowników.
A teraz dwie dobre wiadomości 
-
W przypadku PRO przed zamówieniem płyt, wynegocjowaliśmy od producenta dostęp do SDK i toolchain z możliwością legalnego udostępnienia dla naszych klientów. Nie jest proste znalezienie producenta który w rozsądnej cenie sprzeda płytę w ilości nie miliony sztuk i udostępni źródła które da się skompilować. Nam się to udało - ten etap mamy za sobą
W przypadku PRO będą udostępnione źródła i będzie można dodawać do jądra sterowniki… ale to nie jest dobra droga - patrz punkt 2. -
Implementacja sterownika w przestrzeni użytkownika
Android normalnie nie pozwala na bezpośredni dostęp do urządzeń USB. Kompilacja jądra żeby dodać obsługę komunikacji szeregowej nie jest prosta. Nie da się skompilować wszystkich jąder Android-a
- jeżeli to zrobimy na naszej bramce to i tak będziemy ograniczeni do tylko tego modelu i będziemy musieli to robić z każdym innym jądrem (w przypadku zmiany modelu itd…).
Dlatego postanowiliśmy nie iść tą drogą, a zrobić coś co zadziała na każdym urządzeniu z Android - dodajemy komunikację ze sprzętem w przestrzeni użytkownika (w naszej aplikacji).
Pracujemy nad tym żeby zbudować w aplikacji AIS dom, który połączy port szeregowy USB z TCP socket w systemie Android.
To będzie nasze rekomendowane rozwiązanie w tym temacie.
AisUartBridgeX
Mamy już prototyp, opiszę jak to działa:
- tworzymy serwer TCP w aplikacji - otwieramy input i output stream na jakimś porcie np.
1234 - łączymy urządzenie USB za pomocą kabla OTG
- wykrywamy urządzenie dodane po USB, ustawiamy parametry transmisji i czytamy z niego dane które napływają z urządzenia, i publikujemy je na serwerze TCP. Dane które przychodzą z TCP piszemy do USB.
- w aplikacji łączymy się z portem TCP. Np. zigbee2mqtt łączymy się nie do
port: /dev/tty... ale doport: 'tcp://localhost:1234'
Proof of concept
komunikacja szeregowa z adapterem zigbee2mqtt z telefonu, bez root-a bez kompilowania jądra
DEBUG=zigbee-herdsman* npm start
@Grzegorz_Sterniczuk czy ty sam robisz te adaptery?
Jeżeli jesteś programistą to chętnie dołączymy Cię do projektu. Jeżeli nie masz naszej bramki to możemy się wymienić adapter za bramkę i doprowadzić to do działania razem.
Napisz proszę na info@ai-speaker.com wiadomość z kontaktem do siebie i opisem tego co robisz.
Szukamy stabilnej i mocniejszej alternatywy dla naszego CC2531, może razem to dodamy.
PS
W zbudowaniu tej funkcjonalności pomaga nam kolega, programista z Meksyku 
Pisząc to opieramy się na jego kodach i doświadczeniach z projektu który powstał do komunikacji pomiędzy Android a Arduino. Jak będziemy mieli więcej czasu to opiszemy całą historię kiedyś i przedstawimy naszego Amigo na forum.
Oczywiście jak wyjdziemy z fazy prototypu to włączymy tą funkcjonalność do projektu - wg nas to jest najlepsze droga (a nie dodawanie sterowników do jądra). Zalet jest wiele i docelowo, dzięki temu podejściu będzie można adapter podłączyć do tabletu itd… nie koniecznie do bramki która może nie znajdować się w centralnym miejscu w domu, może mieć włączone wifi, blutooth co nie pomaga zigbee.