On ways.
So.
So thank you all for coming.
The next talk is about Droidian from Bardia.
Please give a big round of applause.
Good afternoon, everyone.
And welcome.
My name is Bardia, as you've heard.
And if you've been following our project,
know me as Fake Shell in the community.
And I'm one of the core devs of the Droidian project.
And if you have any interest in embedded systems, mobile
devices, that's why we're here, obviously.
You might be particularly interested.
So today, our topic of discussion
is going to be Droidian and what we're doing,
how everything works, and how everything goes together,
and why the whole project even works.
No, I'm sure.
Like I said, I'm prepared for that.
OK.
So who are we?
Well, we're a number of fos and privacy enthusiasts
committed in building a free and open source
project and operating system that is user friendly and open
that can be utilized in different environments,
such as phones, maybe even single board computers, et cetera.
Tablets, different things.
So Droidian is, as the name states, based on Debian.
We take the core of Debian and add our own repository
on top of it and add our own so-called finishing touches.
So Droidian utilizes a number of different projects.
Should I go down like this?
OK.
That's too far.
OK, I messed it up.
So Droidian utilizes a number of different projects.
Some of the more well-known projects are Hallyum.
We use lip hybris and Gbinder from Joly.
We use the stack from GNOME, as you guys may know, Fosh.
And we currently have a selection of devices
supported in our official CI or build system.
And I think it should be over 20.
We haven't updated that device page,
so it's not exactly up to date.
It should be 25 or 26.
So devices vary pretty largely from different manufacturers.
Different release states.
We have the OnePlus 3 from 2016.
We have the Pixel 3a, the FX-Stack phones, the Galaxy S9,
Lenovo Think phone.
Like, the list goes on and on.
So the barrier of entry for getting into Droidian and
development and porting is fairly low, because there's
already a number of devices that do exist.
And they mostly cover most of the possible cases in the
Android space.
So for Droidian, one of the main things that people who just
get to the project need to know about is our porting guide.
So the porting guide is mostly split into three sections.
It's the kernel compilation guide.
It's the Routefest debugging and Routefest creation.
Kernel compilation is going to be the initial testing and
compiling, changing a few parameters in the kernel, and
packaging it to get a Debian output, because we need Debian
packages to do over-the-air app kernel updates.
We have Routefest debugging, which occurs after the phone
actually boots into the Droidian root file system.
And last but not least is Routefest creation, because we
obviously need to somehow get built for each device.
So how do we actually get from Android to Linux, or so what
we call Linux?
So on Android, there's usually the bootloader, LK,
loading the kernel, kernel loading the RAM disk.
And the RAM disk does everything to start up the
inner process of the system partition to actually start
the system.
And then system mounts a bunch of stuff, mounts product
now to vendor, and a bunch of other garbage.
So on Droidian, we take the same kernel that there was on
Android, and we change the RAM disk.
We have a modified fork of the Hallym RAM disk, which the
Hallym project and UBPORs used to maintain.
Now, in our fork, we have some support for a bunch of stuff
that we use that is not in the upstream Hallym RAM disk.
The Hallym RAM disk mounts the user data partition, which is
where Droidian actually resides.
We don't use system, which is kind of a basis base, but it
is what it is.
It mounts user data.
It does a bunch of Android bootloader stuff to get
everything up and running.
And it starts in it, which is system D, obviously.
So now system D starts, and system D starts up all the
usual services.
We have system D time sink, the system D resolve, and all the
other stuff.
But then we have our own services from system D. We have
a service that starts a very small container that runs
Android.
And that Android starts and mounts a bunch of partitions,
Android partitions, modem, and everything that the
firmware and the drivers need.
And the vendor script starts, the system GSI script starts,
and we get all the drivers loaded, all the firmware
loaded, and a bunch of interfaces start from Android.
Now, then we have the usual file system of Debian.
There's the user interface.
There's like, file feedback, the end-to-rest.
So from the Android services, we have hardware composer,
which we use for compositing to the screen.
We have audio flinger.
Well, not exactly audio flinger.
It's Droid media, but ignore that.
We have Droid media for audio and camera.
We have the radio interface layer for us name states radio.
And a bunch of other services, lip, perf, manager for power,
NXP, NFC, et cetera.
So all the communication that we do from the Linux side of
things to the Android side of things is done through
Google's binder pipeline, or the binder IPC.
And we'll explain how we actually use the binder IPC, how
we actually communicate with it directly to the interfaces.
So from the Linux services, everything looks familiar kind
of.
There's Fosh, obviously.
There's feedback for feedback.
There's Ophono, kind of ancient.
And because nothing in the modern Linux stack can actually
talk to Ophono, we have Ophono 2MM,
which kind of exposes modern manager interfaces as a drop
in replacement through Ophono.
It's kind of a hack, but we don't talk about that.
Yeah.
So we have Joid.DNFPD.
It's a fork of Sailfish community FPD, which is used
for fingerprints.
We have Call Audio.D as usual for Call Audio.
Again, we have custom backends because Android.
And Pulse Audio, again, ancient, but Android.
And a bunch of other services.
NFC and GeoClue, again, needs its own backend.
But we're going to talk about these later.
So most of the components that we have are not directly used
by the user.
So for camera, which is for Joid media, it's abstracted.
And users just see the Joid.DNFPD camera app.
For modem via Ophono, but users just
see kind of a modem manager sort of imposter.
For fingerprints, this part is completely customized
for Joid.DNFPD.
We just forked the settings.
I haven't had it, everything.
For battery management, Batman, very funny name.
That does the work for battery management.
I started that project as a shell script.
It was a mistake.
So Batman does a bunch of funny stuff, turns off CPU cores,
sets governors, sets power save, whatever.
It doesn't watch nonsense.
And then we have Fosh, which is the user interface.
Again, we maintain our own forcofosh
because sometimes stuff happens, stuff breaks.
We kind of have to maintain our own.
We have bad experiences.
We don't talk about those ones either.
We don't say that in public.
Joid.DNFPD needs to have a good image.
Then we have the encryption service.
Again, a custom tab and settings which uses Lux and LVM2.
And the unlocker, which was, I think, initially developed
for post market OS.
We added a mini UI back end through LVGL.
Again, custom back ends Android.
I mean, it's the usual.
So now how does everything actually go together?
So as we mentioned, we have a bunch of custom back ends.
We have a bunch of custom plugins.
We have the Qt5 camera plugin from the days of, I think,
Canonical, which developed it.
There's the Ofona Binder plugin, which
was developed by Joela, nice of them.
There's a bunch of Pulse Audio modules
that allow us to talk to the audio hell, like Droid Media
itself, not exactly audio.
And get audio through the hardware working, microphone,
speakers, everything.
We have GSTDroid.
Again, talks to Droid Media to give us a nice and shiny Gstreamer
pipeline that we can use for camera.
And well, that's pretty much it.
For back ends, because not for everything,
we can add plugins, not all different pieces of software
accept plugins.
So we kind of had to hard fork a bunch of stuff.
Some of them are not that frequently updated.
So that was good luck for us.
But GeoClue is barely updated.
So we just added the Hypers back end, slap it in,
which just works.
We have the W-Root's Harvest Composer back end.
I don't even know who started that.
I know a bunch of people are involved in that.
It's a mess.
We have the Color-UD back end, which routes a bunch of stuff
through hard-coded values.
What if it works?
And the Feedback-T back end, which
talks to the Android vibrator how through IDEL and HIDL
and gets the job done.
It's not beautiful, but it works.
And for MinUI, as we mentioned for Unlocker,
we added a MinUI back end to LVGL itself,
so it can draw to the screen without GPU acceleration,
of course.
Who needs GPU acceleration in the RAM disk?
Anyways.
So for Woot Animation, I think all this was used by Muff.
We also have a MinUI back end for PlayMuff.
I think it started life as the MoUI back end from JoLa.
I don't remember.
So to actually talk to the Android services,
there's two main pieces that are doing the job for us.
One's Lepipus and one's Gbinder.
They allow us to craft.
I mean, the Pibus has a bunch of compatibility layers
and Gbinder that gives us a way to craft transactions
and send it to the Android interfaces.
And the whole system, how the whole thing works,
pretty much ends there.
Stuff's maybe hacky at times, I'm going to admit.
But it works because we use pre-built vendor services
and a bunch of stuff that was provided by the vendor itself.
Stuff works for now.
Maybe futures too.
I'm joking.
Like, stuff actually does work.
So what is next for JoDian?
Because the services work and the system itself
starts up, everything works for the most part.
But in reality, one of the main issues of the whole Linux
ecosystem is app support.
You don't have apps, must be honest.
And no one wants to develop any either.
No other big companies do.
So I guess start integrating Beidjoy
better into the system.
Getting like zero startup time on Beidjoy,
maybe developing something that replaces Beidjoy,
again a drop in replacement.
And clean up all the garbage that we added.
We have a lot of garbage.
So it's not pretty.
We definitely have to go through everything.
At least I do.
I'm not a good programmer.
We have to go refactor a lot of code, clean up a lot of code,
see what we have to do.
And possibly actually add some new features.
So some of the actual features that I had in mind
that I have been working on was wireless displays,
which has to go through a pipe wire of using
old version of pulse audio.
So it's kind of tough.
So I don't want to do a drop in the basement of pipe wire.
I'm kind of tired of hacks.
So we kind of have to fix up pulse audio to actually get
pipe wire working.
Then we can get pulse audio working because there's
like an XTG portal for it.
So that's one of the stuff in my to-do list
that I actually have some work put in.
Face unlock was something that I've
been working on for the past two months.
We can get face detection working through G-streamer.
And G-streamer will actually move as you move your face along.
I'm going to admit it's like 3 FPS.
But it does detect.
And the rest of the work can be done with OpenCV
because not all Android devices do have the sensor
to do it in hardware.
So that has been in my to-do list.
I've been working on it.
Maybe we can help out other open source projects
if they like face unlock, maybe.
And two other very annoying features
that are kind of deal breakers for others is once MMS.
MMS, we don't have MMS.
I tried many times.
I couldn't get it working.
MMS is very important.
RCA is more important.
But MMS also, at least in Canada and the US where I live,
Android users are always using MMS to talk to the iOS guys.
So MMS is very important.
Dual SIM is very important as a deal breaker for many.
And we have to work on dual SIM.
That is a very big priority for me also.
We've seen many users who actually looked at Android
and they were like, oh, yeah, this is great.
But you guys don't have dual SIM.
So I'm out of here.
That's not exactly the nicest.
And besides all that, we still do
have to work on app support for Linux and the ecosystem.
With LibitVita and GTK4 becoming very mature
and things working out, I have been at the very least
working on porting all the old GTK3 applications
that I've been using to GTK4 and LibitVita.
Not exactly joy-dien specific, but it will benefit everyone.
So that's something.
A lot of applications are very slow.
Settings app, as we all know, is very slow for the GNOME
settings app.
Much of the stuff is not threaded.
Everything is running in a single thread.
It's just horrible.
A lot of code we have, I mean, well, I do have,
that will soon possibly become a PR for many different projects,
making many things threaded.
We at joy-dien have a big PR to optimize GTK4.
Speeding everything up, we've had a user who
was working on a Blackberry, and he was seeing 70%, 80%
performance improvement on his on GTK4.
Because apparently there's a lot of issues in GTK4.
Who could have thought?
And the very last issue is that we don't, as the joy-dien people,
we don't allow community devices in our build system.
So if one of us, Core Devs, has a device,
it can be made an official device.
So like, be added to the build system, get stable builds
and nightly builds.
But we kind of don't have that for other people putting devices.
So you should probably look into having a way to allow community
people to port their phones and have them in our build system.
I know many community porters have worked on devices,
and they saw that, oh, they couldn't add it.
So they just gave up.
And the most important thing, documentation.
And that's something I have to do,
because none of the code I wrote has documentation.
We have to do a lot of documentation.
We don't like, at least the stuff that I worked on basically
has nothing.
I just worked on it.
I slapped it on.
I was like, yeah, it works, whatever.
That one has to be worked on a lot.
And that is at least my to-do list for now.
No.
Don't go down.
Don't go down.
Don't go down.
Don't go down.
OK.
OK.
OK.
So if you want to contribute to Joyden via our device page,
via our website, via our telegram channel,
which also sync to our matrix, I think you can also find
the matrix group for Joyden project.
I don't use matrix much.
But apparently, if you have a group that
has a bunch of channels in it, I don't know.
So you can find us there as well.
And one kind of announcement that I have is we
have been working towards getting phones with Joyden
as the first pre-installed on phones.
What a weird sentence.
We have been working with an ODM to get Joyden phones,
or so-called phones, with a Joyden-based system
installed on them.
And have that be sold to have kind of as a way that 0.64
does it.
But it's like, yeah, we as Joyden developers are doing it.
So we understand the system and we understand the hardware.
So it's going to be much easier to develop on,
because we also understand the system itself.
So you might want to look out for that.
Few relapses, not very labs.
Few relapses, please.
And possibly the bigger news of this sort of project
of getting Joyden-based phones will be coming out in a few
months.
But you can be on the lookout for it.
We have a website at the moment, kind of not exactly the best.
Still being worked on.
We have a survey asking users, if they
wanted to have a phone with a Joyden-based system,
what would they want?
What specs would they want?
What would they want the devs to be focusing on, et cetera?
So you can expect a Linux-based phone sold on the market
in a few months.
Thank you.
Thank you very much for the great talk.
I know we have a lot of questions in the matrix,
so I'm going to pass it on.
So the highest upvoted question right now
is, do you have any plans to switching to motor manager
from Ophono?
OK.
So I have looked into this.
I'm going to be 100% honest with you.
I have looked into this.
I am by no means a professional.
And when I tried getting this working,
I could never get a motor manager kind of back end
to register a command over the binder IPC, the G-binder.
Again, I am by no means a professional.
And this is probably doable.
And it will be a huge step forward,
which will make the whole modem stack a lot better.
It doesn't have to go through this, this, and this,
and this, and this, a thousand things, then
user sees some and gets it working.
So yes, it will be great.
I spent some time.
I couldn't get it working.
But it is in my to-do.
One question.
You mentioned that you implemented a WL roots back end
for, I guess, to get fresh running.
Is there any plans?
For example, I currently use postmarker S on my phones.
This is actually running in mainline kernel.
So I guess it's a little bit of a different situation.
But for example, different other Linux mobile UIs,
like Nome Shell, just the Nome Shell branch for mobile,
stuff like Plasma Mobile, SXMO.
Is there a project to get those running on Droidian as well?
Or is the only focus at this point?
So at the moment, I actually understand the question.
And we have a lot of questions like this,
like getting different UIs running.
So each UI that uses an underlying graphics library
needs its own back end, obviously,
because we have to use Harper Composer.
And I know that there's like VeyFire that uses W roots.
So that one works fine.
There's a bunch of other W roots that works fine.
But as an example, Plasma uses Kavein.
There was what they used to be a Kavein back end
for Harper Composer.
And it's pretty old, or it's really old.
And someone has to revive that to get it running.
I currently don't have the time.
I have a full-time job, and I'm a student.
I'm kind of already under a lot of pressure.
So for GNOME, which uses mutter, well,
that's a beast by itself.
Because Kavein and W roots are modular, somewhat.
But mutter is the opposite.
So the code for the RM back end, or frame by frame,
or whatever, everything is baked in so hard that it's
a very tough task actually adding a new back end.
And let alone maintaining it.
Because no one's going to accept any of our back ends
upstream.
Because no one can test it other than us.
So if someone spends a time sure, but for GNOME shell
with mutter, I really doubt it.
Because it mutter itself.
I might piss a lot of GNOME people off.
I use GNOME myself.
Mutter is a mess, at least when I looked at it six months ago.
Thank you.
How does Droidian support standard Debian, like Bookwam,
Bozi, Deb files for RM64 targets?
Well, yeah.
You can run the packages.
Right now, Droidian is based on Debian Trixie, the testing
branch.
We also have a branch for stable.
Well, we have a snapshot for stable that you can use.
It doesn't have many of the new features,
that is based on the Bookwam.
But any repository you add, any dead repository you add,
if the packages are built for RM64 or the architecture is
marked as all, like Python packages and stuff,
everything will work.
Flatpacks work, Snap packages work.
If app images built for RM64, app images work,
it's just like a computer.
Thank you.
Thanks.
Maybe another?
Yeah.
OK, you.
And then another question from Matrix.
Thanks.
Just a quick question about the strategy,
because you mentioned that all these hacks you've built around
to get it working.
So my initial understanding was that you built Droidian
to foster the development of these apps for Fosh, for instance.
But now you're trying to also have a phone delivered with it.
So does this really make sense to have a device running these,
let's say, many hacks from the start?
Well, yeah, that's a very good question.
Well, we're trying to eliminate every single thing
that we think is like a big hack.
But it really depends on what you consider as a hack.
Is libhybers a hack to you?
Then the whole system is built on nothing.
But to my eyes, I kind of have a different look to it.
And in my opinion, we can slowly get rid of most of the hacks.
Again, we have custom backends?
Fair enough.
But I don't see there as a hack.
But in my opinion, a lot of those can be cleaned
and can be made ready to be shipped on a phone sold to customers.
So it's not that far gone that I would consider a waste of time.
I would consider working on it a waste of time.
I still think that it is very doable getting it done.
Give a big round of applause again.
Please, thank you.