BananaHackers blog


Read the latest posts from BananaHackers blog.

from farooqkz

Special thanks to Simon for editing

In this post, I write about different reasons people choose KaiOS as their primary mobile operating system over mainstream ones such as Android.

Why did I prefer KaiOS?

When I was beginning to enter university, just like many many other students at the same age as mine, I needed a mobile phone. As a student and a bookworm I needed some small and lightweight device to read books, articles, websites and such of these. On the other hand, I had seen how people waste their time in mainstream social medias such as WhatsApp, Telegram and Instagram.

So I took a different approach: I don't get myself a smart Android phone which I could carry Instagram and such these with myself everywhere and waste my time with it instead of socializing and being with friends and family. Instead, I planned to get an Android tablet with E-ink display with which I can read books, articles, papers, websites and blogs and everything else. Because the screen is E-ink rather than IPS or LED, it is almost like a regular piece of paper and thus it won't hurt my eyes.

But the E-ink Android tablet I wanted to buy didn't have access to Cellular data. Only WiFi and Bluetooth. So I needed something to feed Cellular data to my tablet on the go. I needed a phone capable of basic Telephony and Messaging plus hotspot. At that time I had found KaiOS and the BananaPhone which the name BananaHacker is derived from it.

Back then, I looked in KaiStore and barely 100 apps were available for it. I thought I wouldn't need to do anything with my KaiOS phone because I would also have an Android tablet. So I bought 8110, Nokia's first KaiOS phone.

First reason: You want to use KaiOS because you don't want to be a social media addict

You might have the same reason as me preferring KaiOS to Android. You simply feel you shouldn't waste too much time with social media.

Actually there is a working unofficial Telegram app for KaiOS and there is official WhatsApp. I think the ZAP Reddit client is still out there and I started developing a Matrix client, chooj, for the emerging mobile operating system. But will you be able to chat with people for a few hours with the ABC keyboard? I guess not!

Second reason: You want to modify everything

KaiOS 2.5.1 and 2.5.2 are easily rootable. And the System app which is the main app for KaiOS uses Javascript as well as all other apps, including the stock ones. Javascript is not a compiled language. Rather, it is interpreted language. So the compiled Javascript app is very easily moddable. This means you can easily mod the System, Keyboard and other stock apps. Or, like Luxferre, create your own cool replacement.

KaiOS is really lovely if you love modding your phone. Maybe because you are a Geek and you cannot use your phone the way other ordinary people do.

Third reason: You want to be part of the revolution

KaiOS is a new operating system. It's very buggy, the 2.5.x version is relatively slow. And its stock apps are really terrible usually. But it might have a good future(or not). So perhaps it's a good idea putting sometime codding for it and learning it in the hope that it will have some good future. Of course, because of its clouded uncertain future, it is probably not a good idea putting too much effort on it.

Other reasons

There are many other reasons people prefer a KaiOS phone. These reasons include but are not limited to probably longer battery life, being cheaper and maybe more efficient comparing to Android devices of the same price.

I might have missed something or forgotten or perhaps you want to share you own reasons for preferring KaiOS. Feel free to Email me and I will include your opinion here:

fkz [at] riseup [dot] net

from farooqkz

Thanks to Simon for editing

As some of you might know, the BananaHackers group started with the Bananaphone by Nokia. In the past few years, since the launch of KaiOS in 2017-2018, KaiOS Nokia phones were one of the easiest to root using EDL(or not) and super trivial to make them debug enabled using the famous DEBUG dial code. So they are being a favourite among KaiOS app developers and device modders.

And it has been a few months(at least) since when KaiOS 3.0 has been announced and some users have reported KaiOS 3.1 being in existence. Something which the community yet misses, is a KaiOS phone which is “buyable” and at least debug enabled or even better: Easily moddable by rooting.

There are so many exciting new features in KaiOS 3.x which includes much better performance, support of new Web technologies including WebAssembly, newer WebGL, and a bunch of other stuff which you can see a list of them here

According to Nokiamobs(see also this link), Nokia is probably preparing to launch a KaiOS phone, which must be KaiOS 3.x, with 4G cellular data.

Specifiations of the new phone(s) are yet unknown.

Related link


from farooqkz

This is Master Ivan Alex HC(aka Uncle Ivan). I have to regret that both the Gerda order and the Republic, the democracy we had have fallen in order to give their place to the dark shadows of Darth Kai and the Empire. This is a reminder and warning for all surviving coders. Do not return to the Gerda repository and trust only in the source. In time, a new hope will emerge. May the source be with you, always!

— Adapted from Master Obi-wan's qoutes in Star Wars Rebels series


from farooqkz

Special thanks to Mort and Simon for editing

Today, after several months of the first release of FastContact, an open-source and super light contact app replacement for the stock Contacts app, I gave it a try. Perhaps “Super Awesome” is the best phrase I can find to describe my experience with his app.

If you've been a user of KaiOS smart feature phones, you definitely have suffered from the lag and slowness in KaiOS and its stock applications. For some apps like WhatsApp and Email, I don't suffer that much as I don't need them almost every time I unlock my phone to do something with it. The lag has at least two sources:

  1. The KaiOS itself is based on an ancient version of Firefox, which is 48.

  2. The app itself if the app is using JavaScript and/or CSS frameworks which are slow for KaiOS.

Luxferre on the other side has taken the approach to use no JavaScript framework in his FastContact app as well as other of his “Fast” apps, making the app as fast as possible. While I am not sure regarding the neglect of any JavaScript framework, even InfernoJS which has got a performance nearly as good as plain/vanilla JS, the performance of FastContact is more than impressive.

Two other measures for the lightness of an app are Memory and Storage usage. Taking a memory snapshot of FastContact while running shows only 0.5-0.6 MB while for the stock Contacts app on my 800 Tough, it's around 5.5 MB. One of the reasons definitely would be that the stock app shows 20 contacts at a time and has a more complex DOM structure and more complex CSS.

As for load time and storage, because FastContact loads only a little few contacts initially and because of using no “heavy” stuff is less in size which helps it load significantly faster when compared to the stock one.

In the last paragraph of the post, I make you remember that Luxferre is from Ukraine. If you are a Russian citizen perhaps it is a good advice for your government to stop the going war in Ukraine.


Haha, one more paragraph as a bonus: You might be interested in this guide in the BananaHackers wiki which is about assigning FastContact to a hotkey to quickly open it instead of the stock alternative.


from farooqkz

If you have checked recent messages(around 11-01, 3 o'clock UTC. I think it wouldn't be so “recent” at the time you are reading my post), you could see yet another guy or girl interested in developing apps(in this case games) for KaiOS. Since it wasn't the first time someone newcomer in the BananaHackers community interested in app development had shown up, and since they were asking almost the same set of questions every now and then, I thought writing a blog post regarding that would be a good idea.

Here you go with a list of titles and a sentence about what's inside the said section:

  • A wild Mozilla reappears after about 5 years: Some historical words on the origin of KaiOS, Mozilla's late FirefoxOS, and the difference between FirefoxOS and KaiOS.

  • Hardware properties of KaiOS devices: In this section, I've written about what hardware KaiOS devices usually have, including physical keys, the display, connectivity, and other hardware features or properties.

  • Software properties: I've written what type of apps does KaiOS support, where to start developing for KaiOS, what language and technologies you can choose from, and such these.

  • The reasons why you might not want to develop for KaiOS: Here I have mostly linked to another blog post regarding the reasons why you might not want to develop for KaiOS at all.

  • Hardware requirements for the app development: This section is about the main coding device you need to develop for KaiOS as well as the KaiOS development device you can choose.

  • Links collection: I've linked to resources you probably will need while developing for KaiOS.

  • Last words: Last words of the post...

A wild Mozilla reappears after about 5 years

Before going through anything else let me write a few words regarding this Operating System calling itself “Open”. KaiOS is just FirefoxOS or B2G which appeared years ago from Mozilla, by some called the web Robin Hood. I remember at that time it was a trend for almost every company to have their own mobile operating system. You could see Ubuntu Touch from Canonical, Tizen from Samsung if I remember correctly, FirefoxOS from Mozilla, and I suppose a few others which I don't remember right now.

The late FirefoxOS was a web-based operating system for (low-end?) touch devices. This means the operating system was a big browser having web apps running in. And B2G stands for Boot2Gecko. Gecko, according to Cambridge dictionary, is a small lizard with wide feet, found especially in warm countries. You can pet one but I don't guarantee it does not bite! I never had one to pet but geckoes seem pretty cute. Don't they?

A picture of Gecko

However, in the context of front-end development, especially Firefox browser, is the name of an engine:

Gecko is the layout engine developed by the Mozilla Project and used in many apps/devices, including Firefox and Firefox OS. Gecko interprets JS, HTML and CSS plus embedded content like images and draws everything on the screen of the user's device. Gecko among other things includes a networking stack, graphics stack, a JS VM, and many other stuff.

Gecko, MDN glossary

So now that you kinda know what FirefoxOS is, you also know what KaiOS is. KaiOS is a version of FirefoxOS launched in 2018 for “smart feature phones” with no touch support(at least devices launched till now, which are running KaiOS v2.x or v1.0 never had touch support as far as I know). Most of these devices have got an ABC keypad. To read about the hardware properties of KaiOS devices, go ahead to the next section.

Kai means open in Chinese. So KaiOS means open operating system.

— From somewhere on KaiOSTech

Hardware properties of KaiOS devices

Physical keys

All KaiOS devices have got an ABC keyboard, with JioPhone 2 as an exception which has got a nice and soft QWERTY keyboard(see the photo below from tbrrss. This photo was originally used on this wiki page dedicated to JioPhone).

A photo of JioPhone 2 running Luxferre's Wallace toolbox by tbrrss

Other than that all KaiOS devices include D-pad navigation keys(up/down/right/left), Okay or Enter key to confirm things usually(or shoot at enemies in some games), Soft left and Soft right keys, Call key and Power or Back(space) key. Many devices have got one or two more keys like my Nokia 800 Tough which has got a shortcut key above the Call key and Back(space) key above the Power key.

So to sum up you've got these keys on all devices(excluding JioPhone 2):

  • 0 to 9
  • ArrowUp, ArrowDown, ArrowLeft, ArrowRight
  • Enter
  • Call
  • Backspace
  • SoftRight
  • SoftLeft

And these two as optional because you won't find them on all devices:

  • Power
  • Shortcut key

There are also other physical keys on some devices. Like the side power key on the BananaPhone(the other name for Nokia 8110 4G) which you can use to turn the display on/off and power the device on or off. Or 2720 Flip has got that of 8110 and two keys on the side for volume up and down. Not sure if you can capture even of these keys in your app.


Regarding the display all devices have got a 240x320 one(height is 320 pixels and width is 240). JioPhone 2 is however an exception having 320x240 instead. Note that the size of the screen of devices is not the same for all devices but the screen resolution is. That's all that you've got to draw your content on.

Many devices like Nokia 2720 Flip have got another display, usually black and white. According to the website of Nokia, the Flip has got a secondary 1.3-inch front display which displays incoming text messages or caller ID of some incoming call as well as time and date. But I don't think you could use this screen in your apps to display stuff on them officially. And even if you could, it doesn't worth it to add such a functionality to your app which only a few users, comparing to the whole, could use it. Nevertheless, it would be a fun hack but in my humble opinion, not practical.


Now let me write a few words about the connectivity features of KaiOS phones. These “smart feature phones” usually support 3G or 4G mobile data and Bluetooth v4.x. Most of them also have got WiFi support so you won't have to waste your data plan if you are near your work or home router/access point. The other feature they usually have is Internet sharing with USB or WiFi tethering(supporting WPA 2-AES, WPA-TKIP, or no security). There is also (A)GPS but at least for me it doesn't work well every now and then and everywhere I try it. Some suggest it's not as good as some of an Android phone.

Both my KaiOS phones, the late Bananaphone and the Tough support 4G mobile data on the primary SIM card and I suppose 3G or H on the other SIM card. Of course, you probably could have 4G on both cards using this trick from the BananaHackers wiki(the origin of it is the BananaHacker website, however, added there, by Ivan Alex HC).

4G or 3.9G?

The 4G connectivity of some KaiOS device is not like a real 4G. According to my experience and reports from a friend of mine named Ivan Pasev, KaiOS limits(or has the limitation on) the maximum bandwidth you can use. It's still faster than 3G but probably slower than the typical 4G you would have on most Android phones.

Other hardware features

Physical ports

KaiOS devices in general have got a microUSB port supporting USB 2.0 only which can be used for debugging, sideloading apps, Internet sharing, charging, and EDL if your device has got a Qualcomm chipset. They also come with a 3.5mm audio jack for audio input and output. Nothing new compared to other phones. Huh?


Compared to Android or iOS phones, the Camera(s) of a KaiOS device hasn't got anything to say. Nokia 8110 4G(aka the BananaPhone), 8000 4G, 2720 Flip, and 800 Tough have got only a single 2 Megapixels rear camera with no front one. 6300 4G has got only a rear VGA camera with no flash.

However, according to KaiOSTech's device list, there are many other devices with both rear and a pretty weak front or selfie camera. I would like to just name a few:

  • Akeza 4G, front: VGA, rear: VGA
  • KaiOS ONE, front: VGA, rear: VGA
  • Digit 4G Bold, front: VGA, rear: VGA
  • myPhone Up Smart LTE, front: VGA, rear: 5MP
  • ...

Processor, Memory and Graphical processor

I am lucky to have a Nokia which uses a Qualcomm Snapdragon processor with 512MB of RAM. Many devices have got only 256MB. Newer Nokia phone models like 8000 4G use a higher version or model quad-core Snapdragon instead of dual-core like my 800 Tough.

On the other hand, not all are lucky like I am. According to the BananaHackers wiki(which its content mostly comes from written by the founders of this community including Ivan Alex HC), there are devices with Mediatek based or Spreadtrum based chipsets. Which in some people's opinion are not as good as Qualcomm's. I cannot comment on this since I'm not much of a mobile hardware geek. Also, there are devices whose chipset was never specified anywhere as far as we know.

Regarding GPU, the KaiOS devices of Nokia which have got 512MB of RAM and Adreno as graphical processor unit, can run Christian Waadt's AirshipCombat 3D single and multiplayer game very well. It's an action shooter 3D game for KaiOS and a few community members, especially one, were addicted to it, at least for a while! I'm not sure if Christian has the game's server still up so that you could still test the multiplayer part of the game. But you always can test its mission-based single-player mode. You can read or see more about this game through this link on BananaHackers' webstore and perhaps download it and sideload it to your device. There is another 3D game for KaiOS, named Marble3D or something a lot like Neverball, which I was playing on my late Bananaphone and was very fun, fast and smooth.

But that's not the end of the story! While these two 3D games were running smoothly on my device with Snapdragon and 512MB of memory, I remember Christian had reported that he had problems running his game on devices with 256MB instead of 512. I don't remember if he finally solved the problems or not. But if you are going to write a 3D game for these devices, I would recommend you get in touch with Christian. He is(or at least used to be) available on BananaHackers chatrooms available through Discord and Matrix(here's a link only to app development room, in the case your client does not support Matrix spaces)

Farooq's dream KaiOS device

I always wished there was some non-Jio KaiOS device available in my country. With a soft keypad like you see in that photo of the lovely JioPhone. Perhaps with 8GiB or 12GiB of internal memory instead of 4, a quad-core processor, and at least 1GB of memory(RAM). But not always things go according to our wishes and not always everything's in our hands.

Software properties

As you have read earlier in this post of mine, KaiOS has come from the ashes of Mozilla's late FirefoxOS which is basically a big browser with multiple tabs(called web apps). FirefoxOS was for a variety of Android touch devices. KaiOS, however, excluding KaiOS 3.0, doesn't support touch at all. And for KaiOS 3.0 which is still not out at the time of writing this post, there are whispers that it would support touch devices. But we can't be certain till a while later we see KaiOS 3.0 devices.

So where to start?

Obviously, you need to know programming and coding if you want to write apps for KaiOS. So I'm not writing here about how to get started in this Computer Science area. If you don't know to program, you should already learn that. Like you cannot go to the third level before you haven't passed the second one. And there's no lift! It doesn't matter what language or technology you start in my opinion. It just does matter that you start. If your goal is writing apps for KaiOS or Front-end development, you could start with Javascript but there might be other options as well which I have written a little bit about them in the later sub-sections.

What language(s) should I learn?

First of all, English and I am serious! You'll need English to read the stuff on the Internet and learn from there as well as being in touch with other community members. CS is not the only area of science that requires people to learn English before anything. Nowadays, English is the language of science and scientists and if you want to access sources of knowledge you must learn it. Just like one had to learn Persian and Arabic languages in the Islamic Golden Age, in the past pre-modern days if he or she wanted to gather knowledge from the others.

As you now know, KaiOS apps are web applications. This means most likely you want to go with Javascript, CSS, and HTML. There is another option, too: Write in like C, C++, or Rust and compile them to some sort of Assembly! In theory, you can do so for a variety of languages. But in reality, there might be no good toolchain or compiler or possibly nothing at all for your favorite language.

But what is this “Assembly”? I'm referring to asm.js and WebAssembly or WASM which you could compile your apps to one of them. asm.js is a subset of Javascript. Note that just KaiOS 3.0 and later support WebAssembly. On KaiOS 2.5 or so you could use just asm.js which is slower than WASM. You can read this post on Mozilla Hacks if you want to ask why.

Does it mean you could abandon the sloppy Javascript? I'm unaware since I've never entered this area. But I am certain about a few things:

  • You probably can use a language like Rust to write almost all parts of your app and abandon HTML, CSS, and JS. For example, see egui project on Github which doesn't use HTML at all. Everything in pure Rust using WebGL compiled to WebAssembly. See their demo here with a browser supporting WASM.

  • You surely can have certain parts of your web app in, for example, C++. By using a C++ library compiled to asm.js(or WASM for KaiOS 3.0).

I'm going with the sloppy Javascript. So any frameworks I could use?

This section is for those who want to go with Javascript for whatever reason. Perhaps they are starting programming and Javascript is way easier than a language like Rust. Or perhaps just because they want to write a simple app and don't want to bother with compiled languages.

You can write your dream web app for KaiOS using vanilla Javascript and not using any framework. This brings a great performance compared to using most frameworks. Also, you won't have a build or compile process before you could test your app in the browser. But not using any framework ruins maintainability overtime when the code size grows. In my opinion and experience, if your web app is going to get bigger than small or trivial, it would be much better if you had used some framework.

However, you may not go with any framework out there. Compared to normal web app development, there are a few things you'd better consider including these:

  • There is no mouse or touch on KaiOS devices. This means the navigation and control are completely done by keys. Nevertheless, there is an exception: you could enable “emulated cursor” in your app's manifest. After that user will have a cursor that could move it using D-pad and click anywhere using the Enter or Okay key. But that is not convenient for users at all and also you won't be able to use the full capacity of the device inputs. Not to mention that it is impossible for something like Christian's AC3D which I've named in the “Processor, Memory and Graphical processor” sub-section.

  • As I said in the “Display/Screen”, the screen resolution is pretty low. About 10 pixels shorter in height if you have enabled the status bar in the manifest. Most likely about 10 pixels less for Softkey labels.

  • The most important thing: Performance, performance, and performance! Firstly you've got only 256-512MB of RAM some of which the operating system itself uses. Secondly, the processor used by KaiOS devices is not so powerful. 2 or 4 cores running at 1.0 to 1.4 GHz usually. And the third concern is that you are developing for mobile with small batteries with a capacity of about 1500-2500mAh. You absolutely don't want to drain all the power saved in the device's battery by using some nasty and heavy framework doing hundreds or thousands of unnecessary or avoidable operations in a second.

So after all these, especially the last one which is performance, you have to chicken out many frameworks, probably including ReactJS. And with any other framework, you would want to optimize it enough especially for memory consumption unless you want the OOM killer to commit an unforgiving crime(from your point of view as the developer of the app and not as a user) and murder your app!

I personally use InfernoJS after some experiences with pure JS(no framework) in many of my apps like, Fooplot, SimpleQuran or toys like TalkingBot. Inferno is a fork of the famous ReactJS optimized for mobile and high performance. According to benchmarks on Inferno website, it is just a bit worse than Javascript with no framework while it brings good features of ReactJS(it is unclear, at least for me, that such a performance is gained by disabling normalization or not). This framework is also has been suggested in KaiOSTech's developer FAQ here. And I've heard by some, Inferno is what KaiOSTech itself uses for stock apps of its operating system. However, I can't confirm or deny that.

After all these, InfernoJS is not the only option you've got. I've seen many using other frameworks. I will name a few in brief:

According to the benchmark on Inferno website and many other benchmarks which you can easily find using your favorite search engine, for example this one on Medium, all these frameworks provide better performance compared to ReactJS.

Let me end this part with a few words regarding other concerns you should have:

  • The CSS you use is important too. You'd better not forget that! KaiOS, excluding v3.0, hasn't got Quantum engine

  • The library and modules you use are just as important as the framework you use. They must be optimized for performance especially memory. Remember the OOM killer? However, sometimes you have not got many choices. For example for Chooj it seems the only option I've got so far is matrix-js-sdk. Also, you might need to modify the library you want to use, a little or more than a little, to suit your requirements. Again for Chooj, I have to somehow make mozSystem property enabled in XMLHttpRequest or CORS will block the requests I make.

The reasons why you might not want to develop for KaiOS

I've written a separate blog post about reasons one(mostly a user) would not want to use a KaiOS device. Writing apps is useless if there are no users to use them. Right? However, there is no absolute good or bad operating system. I highly recommend reading that post or at least the titles inside if you are thinking to spend time and effort developing apps for KaiOS, especially as a real job and not only a fun thing.

Hardware requirements for the app development

So you are sure you want to develop for KaiOS? Firstly you need a PC or laptop or something with a comfortable and fast keyboard to code on. The good news is that you do not need 8GB of RAM only for Android Studio or 4GB for Flutter! You only need enough for these:

  • A Firefox tab which you test your app there in most cases.

  • 2 or 3 more browser tabs to search stuff on the Internet and read them.

  • WebIDE to deploy your app to your KaiOS device and also to debug it. You probably could use command-line tools like Luxferre's gdeploy or Fabrice's b2gclitool which eat less of your valuable RAM.

  • A Matrix client to join BananaHackers Matrix rooms so that you could get in touch with the community and perhaps ask questions from them. Fortunately, there are a variety of Matrix clients for many operating systems including but not limited to KaiOS, Windows, Android, GNU/Linux, and OS X. From Terminal-based Weechat to graphical and memory hungry Element. The choice is yours. See a list of clients here

  • At last the Operating System you use also will consume memory. If you don't have much memory available, you could go for a pretty light-on-memory but yet well-supported Linux distro. For example those with XFCE or LXDE as graphical shells. You could alternatively use just a window manager like Openbox or my favorite tiling WM, i3 which eat much less memory compared to something even like XFCE.

Another device you need for KaiOS app development is obviously a KaiOS device. But not any device. Of course, you should be able to install your app on your KaiOS device through your other device, say your laptop. This process is called sideloading and you need to enable debugging mode on your device to sideload apps. The process of getting debug mode enabled is not the same for all devices. On some nearly impossible or really hard and on some is easy like prey. You can read stuff on the wiki or the website.

If you need quick advice, most community members, including myself, will suggest Nokia phones for development. The reason behind this, other than the fact that a Nokia device is unlikely to be unavailable in your region, is that enabling debug mode on Nokia devices is as easy as dialing *#*#33284#*#* and voila! A bug icon will appear in the status bar meaning now you can sideload apps to your device through your computer! There are, however, at least two confirmed exceptions: Nokia 2720 Flip and 800 Tough if you upgrade their firmware to v30(do not confuse with KaiOS v3.0 that's a different thing). Fortunately, before the OTA update become available in my region, a friend told me not to upgrade to firmware v30. And thanks to him, I did not.

While I tried to put as many links as possible in the content to give you clues for further reading, there are many links which either did not fit in the content, or I think I would better repeat them here.

  • BananaHackers wiki and website: Contains handy resources on rooting different KaiOS devices, developing on them, code snippets, device APIs, and much more. You can contribute and add content too! Just ask for a wiki account and permission to edit and add pages. Any good contribution to the wiki shall be appreciated!

  • BananaHackers chatrooms on Matrix and Discord: You can keep in touch with the community, ask from them or answer their questions and share the progress on your work with them. As always don't ask to ask just ask!

  • Unofficial KaiOS development wiki by alego4710: Contains useful resources regarding app development for KaiOS.

  • B2G docs on Wayback machine: These pages are super helpful. At least the APIs part has been so helpful for all of us. It is so unfortunate that Mozilla removed these from MDN. If the Wayback machine link did not work for you, there is an alternative link from the University of Chicago. And finally you might want to check out this Github repository to self-host these or for offline use.

  • Adrian's KaiUI: It has got UI components for creating KaiOS apps. It is in ReactJS but you could easily use the (S)CSS files and port to other React-like frameworks. For example in my project, Chooj, I have ported many of those which I needed to InfernoJS. See this directory on Chooj's repository

  • nadim's KaiUI: It has got fewer components compared to Adrian's. It still seems nice.

  • KaiUI topic on Github: You can see other KaiUIs.

Got any other useful resources? Feel free to tell me about them by commenting on this post and I will add them to the collection.

Last words

I am not a professional developer and my knowledge is limited. Feel free to contact me, either by commenting under this post or emailing me or pinging me on Matrix, if you think something was written not right by me or perhaps some of my writings were not clear enough.

While I would be happy to answer your questions regarding app development for KaiOS if you contact me somehow, I highly recommend that you ask in the chatrooms and if you want my attention, you could ping or mention me there. This way others could enter the discussion. Perhaps their answers are faster or more correct than mine. Also, others could use your answered question and benefit from it. Of course, this does not mean I will not answer your questions in private whenever I can.


from root

If anyone wants to write on this blog, email Farooq with a sample Kai post of their own and he'll reply with an invitation link as soon as possible.

Here's the email address:

fkz [at] riseup [dot] neeeeet

Note that it is not neeeeet but robots don't know this :))


from LolloDev5123 – an application to aid in hiking

coolappbanner Hits License Checks CommitActivity Starts

Hello everyone! Im new here to this blog, and in my first post, we'll talk about an application I have been adapting to my needs and made open source some time ago,

How I started off

I started off forking, I was full of ideas at the moment, unfortunately, some days later I had to go in vacation and left my computer at home, but wait! I built it later at my location so I could continue development! I had made lots and lots of updates, automatically fetch location, weather, accuracy, and wait, I had an idea that was supported by a friend, iGameEveryDay06, I suggested that I should edit the app to fit the style of KaiOS, it seemed pretty easy, but then I realized everything was written in react, which needs to be compiled, minified, it's pretty annoying. One day, when I was hopeless, Cyan linked to me a GitHub Repo containing native code for KaiUI, it looked beautiful, it was still difficult to implement, but then I realized I could easily add the item class to make the items selectable, once I implemented it enough, it seemed like it would be more difficult to revert back to the old modified style.

What i am currently working on

Im currently working on adding .kml file support, fix a SoftKey bug and maybe improve the code as it is currently a mess + all of the random fixes I do which makes it 100% optimizable if some javascript god happens to run across my repo and make a giant pull request :)

Help me

If you want to support us (me and perry share bits of our code so and will be always updated), the Repo is here:

Some screenshots

screen screen screen screen screen 5cb.png)


from affe-null

In the last post I wrote about the #ApiDaemon. In this post, I will show that it is possible to add “add-on” services to the daemon, and also explain what else the daemon does.

Remote services

Remote services are like plugins for the API daemon. Unlike normal services, they don't have rust libraries that are compiled into the api-daemon binary, but instead run as a separate “child” daemon. When needed, the API daemon starts the child daemon with the environment variables LD_LIBRARY_PATH set to the remote service's path and IPC_FD set to a file descriptor number that is used for IPC between the API daemon and the child daemon.

General structure

Remote service daemons are located in subdirectories of /data/local/service/api-daemon. The subdirectories are named after the service. Each subdirectory should contain at least a daemon binary but can also have a valid_build_props.txt file. Remote services also need a JS library in the http_root. For example, the wavoip2 service contains the following files:


The valid_build_props.txt file contains a whitelist of values of If the file exists, the service is only considered valid if matches one of the lines and SELinux is in enforcing mode. wavoip2 is even more strict: Even if the daemon does start, it still checks for SELinux enforcing and values. Because of this, WhatsApp calls don't work on rooted or soft-rootable devices. However, you can spoof SELinux enforcing with the following commands:

echo -n 1 > /data/local/tmp/enforce
mount -o bind /data/local/tmp/enforce /sys/fs/selinux/enforce

And if you then run setprop QC_8905_3_10_49_SEC_1, wavoip will start successfully.

I haven't figured out the IPC protocol yet, but looking at the API daemon's source code will probably help:


The API daemon also serves the #KaiAds SDK for privileged apps. This is probably used because of CSP restrictions that apply only to privileged and certified apps. Newer versions of the SDK provide a “SDK loader” that decides whether to load the real SDK from or


Another thing which the daemon does is telemetry. I first noticed this when I tried enabling SELinux enforcing to get wavoip working. After running setenforce 1, my phone suddenly became very slow, and when I looked into logcat, there were a bunch of lines saying that the telemetry process couldn't read from /proc/kmsg!!! Later I found out that this process belongs to the API daemon. This means that the API daemon reads the kernel log messages for telemetry purposes.

Also, I found the following lines in the daemon's configuration file:

enabled = true
send_app_opened_events = true
token_uri = ""
metrics_uri = ""

so the daemon also sends “app opened” events to KaiOS.

All of this can be disabled by setting enabled to false. But KaiOS also provides development versions of the API daemon that have enabled set to false by default: I will write about the packages.* domains in the next post.


from affe-null

You might have already heard that #WhatsApp uses some undocumented APIs that are built into the #KaiOS system. These APIs are powered by the api-daemon, a daemon which lies at a lower level than Gecko. In this post, I will explain what I have found out about this daemon.

The api-daemon is written in #Rust, and provides several “services”. Each service has two parts, the JS client and the Rust library. The Rust library is linked into the api-daemon executable. The JS clients are accessible via HTTP at<service>/<script>.js and expose APIs in a lib_<service> variable. A pre-installed version of the daemon is available in /system/kaios, but it is copied to /data/local/service to allow updates without modifying the system partition.

Using the APIs

To demonstrate the usage, let's create a simple app called “Daemon Test”. We will use the telephony service. Although it is meant to be used to get and set the call state, it seems that real calls have no effect on the reported state. However, the state might reflect ongoing WhatsApp and other VoIP calls.

To use the APIs on KaiOS 2.5, we need the external-api permission:


  "name": "Daemon Test",
  "launch_path": "/index.html",
  "description": "An app to demonstrate api-daemon functionality",
  "type": "privileged",
  "permissions": {
    "external-api": {}


<!DOCTYPE html>
    <div id="callstate">Loading...</div>
    <script src=""></script>
    <script src=""></script>
    <script src=""></script>
    <script src="daemon-test.js"></script>

We can now use these APIs as described in, except that we will need to replace localhost with localhost:8081. Note that the documentation is for KaiOS 3.0, but on 2.5 only the telephony, libsignal (for WhatsApp) and tcpsocket services are available. You can also look at the api-daemon source code, which is also only for KaiOS 3.0.

First, we need to set up a sess variable that stores the api-daemon session:

var sess = new lib_session.Session();

Then, we write some handlers that get called when the session connects/disconnects:

function onsessionconnected(){
    /* handle session connect */
function onsessiondisconnected(){
  /* handle session disconnect */

And after that we try connecting.'websocket', 'localhost:8081', 'secrettoken',
  {onsessionconnected, onsessiondisconnected}, true);

Here is the final code:


window.onerror = function(e){
  // Error handling

var sess = new lib_session.Session();
var el_state = document.getElementById('callstate');
var toggleCallState = null;

function callStateChangeCallback(state){
  el_state.textContent = state;

// Set up session callbacks
var onsessionconnected = function(){
  alert('Session connected');
  // Get an instance of the telephony manager
    alert('Got Telephony manager');
    try {
      // Show the call state
        el_state.textContent = 'Call state: ' + state;

      // Show it again if it changes
      manager.addEventListener(manager.CALLSTATE_CHANGE_EVENT, function(state){
          el_state.textContent = 'Call state: ' + state;

      toggleCallState = function(){
        // Get the call state
          // Set the call state
          manager.callState = state ? 0 : 1;
          alert(state ? 'Idle' : 'Calling');
    } catch(e) {
    alert('Failed to get Telephony manager: ' + JSON.stringify(e));
    toggleCallState = null;
var onsessiondisconnected = function(){
  toggleCallState = null;

// Initialize the api-daemon session'websocket', 'localhost:8081', 'secrettoken',
  {onsessionconnected, onsessiondisconnected}, true);

window.addEventListener('keydown', function(e){
  if(e.key == 'Call'){
    // Toggle the state if 'Call' is pressed and the session is ready
    if(typeof toggleCallState === 'function') toggleCallState();

There is a lot more to this. I will also make a wiki page, and some more posts about things such as the updater-daemon and remote services.

More tags: #ApiDaemon