We’ve all been busy this past year, and we feel it’s time to share some of the things we’ve been working on behind the scenes. With the expansion of Bliss OS, Android-Genric Project and others on the PC side, there has been a lot going on that hardly anybody knows about, so here’s a rundown on what’s happening.
Behind the scenes, we are working to update Android 9, 10 & 11 branches of Android-x86. First, with the arm64 updates we worked out months ago with Bliss OS 11, so those will be heading to the pie-x86 branch along with some commits for Taskbar also to help move that to a prebuilt method of inclusion that will allow updates through Play Store.
The Android-11 updates will likely run a little behind as we would like to also update the Android 10 branches with all the progress we have made elsewhere that hasn’t been merged upstream yet. So please be patient for those as we are working on it, but it takes time.
In other news, Android-x86 Project’s Maurossi has some highlights about development on the graphics stack and the upcoming work on it’s q-x86 & r-x86 branch:
Mesa 21.0.0 was kept in building state and working for drm_gralloc, gbm_gralloc and minigbm gralloc1 (intel), nouveau threading WIP does not make nouveau stable with NVC0 chipsets, so nouveau will most probably stay blacklisted in oreo-x86 and later. minigbm with generic dri backend works with r600, radeonsi and nouveau (with cursor tiling artifacts, just mentioning as I was hoping that nouveau could become stable) – as a side note rsglobal effort will be shifted to mesa libgbm based backend and generic dri backend with minigbm “own gbm buffer management” will be abandoned. as part of the benefits i965 should start working, while it is now crashing.
drm_hwcomposer rebase to main branch with the overhead of patches for Android P does not seem to work better than q-x86 branch, some changes in the planes composition have a negative effects on x86 GPUs resulting in black or shadowed on main buffer of System UI window, which forces to disable HardwareComposer, so for x86 devices drm_hwcomposer is not as useful as it used to be and drmfb-composer works ok.
If Android R 11.0.0_r24 and later supports only binderized HALs we will need to abandon drm_gralloc and at the moment gbm_gralloc supports i965, r600, radeonsi, while nouveau is still affected by cursor tiling artifacts, should it became stable with finalization of threading support.
We are also waiting to see if minigbm with generic backend will materialize in the next months.
As a side note, Vulkan API is broken with current r-x86 unpublished manifest, but it is pretty much fine with q-x86 even with mesa 21.1.0-devel and kernel-5.12rc2, where testing is successful with V1 Benchmark Pro X64, so there is a problem with the r-x86 source still.
In other SG development, we get some audio improvements with HMTheBoy154’s (Huy Minh) libncurses + alsa-utils is ready to compile, the good news is that if you compile libncurses with a Gearlock system you won’t need to set and copy terminfo anymore since it is included with Gearlock. For alsa-utils we will have alsamixer:
This ncurses tool will help user interact with audio config easier like Linux. Which means users can control their audio I/O 90% so far. The remaining 10% left is switching devices, between multiple inputs/outputs which this tool doesn’t do but 2 props (hal.audio.in and hal.audio.out) do, so for this, we are still looking for a way to edit those effectively also.
Utzcoz has converted BoringdroidSettings to kotlin and add spotless to check code style for it. He has also added spotless to BoringdroidSystemUI. The next step will start to add tests to those apps. There are two features added to BoringdroidSystemUI, adding tooltips for all app state icon, and drag and drop to remove window for all app state icon. He also changed the updating policy for the Boringdroid, and will focus on the newest Boringdroid version, for example, current is boringdroid-11.0.0, and develop new features and bugfixs for it only moving forward. Unless some very important features are need by users, most new features will only be on the newest version available due to time and development constraints. Another thing the Boringdroid will do is to delivery BoringdroidSystemUI and BoringdroidSettings with apks to the Boringdroid, and separate the development of those apps from the system, that will help to remove Android.bp compatibility to let the app use the newest version of dependencies, and other awesome libraries.
Things are starting to take shape with us and Astian co-leading the project. We have worked out most of the “how” for a new foss vendor based on Astian apps and services, and have been working hard at a complete rewrite of AG from the ground up to better support end users. Some of the things on the table for that rewrite are modular addons, a GUI, integrated manifest and project folder handling, and much much more. Some of the work has also been done on coding the new GSI scripts, and adding x86, x86_arm, x86_64 & x86_64_arm64 GSI targets.
The next steps for AG will include working out a NEW set of scripts to help handle the import/export of many common ROM device trees, and with luck, figuring out a way to determine if a device tree requires something not already in the source, and pull it in. The other side of our planned AG expansion will be to add multiple options for further customization of the branding on our builds.
The entire Astian team has been working hard at laying the groundwork for our next few steps in development, setting up repos, servers, community threads and diving in deep on planning our next few steps as well as working on developing the plan for a number of the apps we have in store. Astian Cloud updates are starting to roll out (here), and this is step 1 for our future plans for Astian Services. We are also planning out hardware strategy for Android-Generic Project with Astian and will be releasing some information on those developments soon as well. Stay Tuned
JackEagle has started transitioning from ROM Development to the PC side of development and we are working on moving most of Bliss development to this side for the time being as we feel the PC side of things is where we have been able to have the greatest impact on the community. This transition is also taking place in order for us to not have to stress so hard over the tremendous workload on our shoulders, so we can learn to enjoy what we’ve been doing once again. As many ROM teams can empathize with, working it all alone is not easy and tends to suck the fun out of the project faster than anything. So we figured it’s about time we unite our efforts and work together this round.
With that being said, we are working on a ton of other updates to Bliss as an org. The first of those updates comes in the form of a redesigned logo and branding guide for Bliss.
More updates for Bliss Infrastructure are right around the corner, including social media updates, and our next onboarding phase. That’s where we are going to be focusing on bringing on new talent for design, app development, ROM/OS development, and web development. We will also be taking steps to ensure that members of the team do not feel pressured from development stress, as well as making sure that the toxic parts of the community are filtered out of their workflow. We want this to be as Blissful as possible for everyone involved, so we are taking our time here to ensure an exemplary solution is executed.
Bliss Family of ROMs has teamed up with https://astian.org and together we are planning big changes for Android Generic Project, giving the community access to a full suite of FOSS tools, android apps and services, all without compromising user data. We welcome Astian to our family in this endeavor and look forward to working together in our joint vision of Android on all devices.
Let’s start with what this may mean for Android-Generic Project.
This partnership represents the impact we can have when we build tools for more than just ourselves. So with keeping that tradition, the plan is to expand Android-Generic Projects tools into supporting even more devices is a given. But we’re planning even more changes that will offer the community a suite of FOSS apps and services that can offer users peace of mind in knowing their data is safe and secure, with no intrusive advertising or sharing their private data.
Some of the apps we will be working on through this partnership include, but are not limited to:
On-Screen Keymapper (for non-touchscreen devices)
Office applications (in collaboration with Collabora)
And many more!
So what does this mean for Bliss and other ROMs?
Well, this means that there will soon be another vendor option for FOSS apps, and it will include an array of apps that all projects can benefit from. The plans are still being finalized, so as soon as we start moving forward, we will be sure to make another announcement post.
Our Next Steps
The plan is to finish up on a little internal restructuring of Bliss and start with accepting new team members using a revamped interviewing process. This will allow us to better support the needs of each project under the Bliss umbrella in finding the talent they all deserve.
We look forward to adding new team members in the very near future.
Note: this post is for developers and maintainers looking to join Team Bliss. Users can disregard this post.
We’re looking for potential maintainers for our next version of BlissRoms, BlissRoms 14!
For this year, we are tightening up our maintainer application process and imposing certain requirements for new maintainers. All new maintainers must meet the following criteria to be accepted, barring any special circumstances. If you do not meet the requirements but believe you have a unique reason to be accepted, please reach out to the administrators at Team Bliss.
You need to understand English. Many of our internal documentation and tools are written in English. In the past we’ve had some unfortunate instances where maintainers did not understand our directives and caused problems. Therefore, all maintainers must have a reasonable comprehension of English in order to be accepted.
Your device must be buildable. Please do not apply in the hopes of getting your device maintained by us. That’s not what this program is for.
Build artifacts must be flashable as-is, without any modification. Unzipping and swapping out the kernel image, editing system files to force certain features to work, etc., are not allowed. Build artifacts should retain their original file name.
You should be able to use Linux, git, and Gerrit. In addition, you may have to run Python scripts on machines you are building ROMs on to upload your builds.
You must have a commit history on GitHub for at least 1 year.
All device trees (including kernel and vendor) must be public at the time of application, barring any legal problems like DMCA takedown requests. Particularly, if your vendor repository is prone to DMCA takedowns, please reach out to an admin before applying. There are no exceptions for device/kernel trees. Dependencies of the device tree (such as supporting libraries) must be public as well.
You must release builds every two weeks, minimum. Please set aside enough time for maintaining your device.
Also, this year we are dropping the requirement for XDA threads. If you hate interacting with entitled users then you don’t have to! We are also dropping the requirement for support groups on Telegram.
All maintainers and developers of Team Bliss must abide by our ToC. These are really basic conditions, so don’t worry about signing away your soul or anything. These terms mainly deal with common decency to others and regulations like the above to agree to.
Note: this post is for developers and maintainers looking to join Team Bliss. Users can disregard this post.
Hello! As part of our move to Android 11, we will be closing new sign-ups for the Android 10 (Q) BlissRoms maintainer application. We will come back with a new maintainer program for Android 11, so check back here often and we will announce details once we have them!
Hey everyone! Exciting time of the year. iOS 14 is coming out soon, right?
…I’m kidding! I know you guys are itching for the Android 11 builds, so before we start this month’s worth of announcements, I want to briefly touch on these points below.
When will Android 11 come out?
Android 11 came out a couple of days ago, so obviously we should have a build ready to go for everyone, right?
Well, no. That’s not how this works. The bring-up for Android 11 will be a tedious and long process and it will definitely need help, in the form of people spamming our chats asking for the latest and greatest Android 11 BlissRoms build.
…I’m obviously being sarcastic. Don’t do this. Please!
Asking for ETAs is a big no-no in the Android community, and if you don’t know this already just try going to the forum on XDA-Developers and ask when a custom Android 11 build will be out. You’ll be banned before you can finish asking “ETA?!”
So don’t ask us.
That being said, we have a general timeline set for beta releases in a couple of months, and general releases after that. This is not a concrete timeline and it is subject to change at any time. So please don’t message us and say that we lied when we don’t ship builds in a couple of months. We didn’t. You just didn’t read our announcement fully.
Will my device be supported in Android 11?
Right now, we cannot be sure. So please don’t ask about this, too.
Oh, speaking of device support…
Unofficial builds are unofficial builds
We are happy to see that members of the community are adding support for devices that are not on the official roster, by building unofficial builds. However, we would like to remind you that as much as we are grateful to developers and maintainers helping to create a better ROM community, we cannot endorse these builds in any capacity.
This has particularly become an issue as some unofficial maintainers have begun to launch builds to “compete” with official builds, claiming more functionality and bug fixes. We have even received a number of abuse reports from maintainers, claiming that unofficial maintainers are encouraging users to threaten or harass the official maintainer, sometimes doing it themselves. We never condone this type of behavior and we are really saddened to see how abusive some members of the community have become. Please do not support this behavior yourself and steer clear of builds built by these toxic members of the community.
Another issue with unofficial builds is support. We cannot support devices we don’t own. We just can’t do it. Period. This means whatever bug or snag you run across while running an unofficial build should be forwarded to the unofficial builder, not us. Our public community chat on Telegram is only focused on providing support for official builds, and not unofficial builds. We just don’t have the capacity to do it. Sorry.
If you, as a developer, would like to build official builds, then please consider applying to our maintainer program at Team Bliss. We have instructions on how to do just that on our community chat.
Oh, right. Regarding the community chat…
Spam moderation in community chat
In the past month we’ve seen an uptick in spam, particularly threatening and abusive messages from trolls. We are trying our best to filter them out, however we cannot be available 24/7 and some of these messages may slip through the cracks.
If you notice any bad messages on our community chat, use the /report flag while replying to the offending message to report the message to admins. Also, right click on the message and select “Report Message,” then select the appropriate abuse reason. This will alert the Telegram team to the abuse and they will be able to shut the spammer down.
We appreciate everyone’s patience and are working towards a solution that will preemptively block spammers before they even join. Further details will be announced soon. Thanks!
Updated OTA announcement
We recently overhauled our downloads infrastructure and that caused some of our server API URLs to change. As a result, the old OTA app bundled with old builds of BlissRoms will no longer work.
To check if you have the old OTA app:
If your BlissRoms build was released after August 23rd, then no need to worry! You already have the patched OTA app.
If your BlissRoms build won’t update even if there is a new version listed online it’s possible your build does not have the patched OTA app.
If you are on a build before August 23rd, please update manually by downloading and flashing a new build .zip. You only need to do this once!
In the future, we are looking at OTA-OTA solutions (sounds weird, right?) so that users do not have to repeat this. We’re sorry for the inconvenience!
Great, so let’s see what changed this month for BlissRoms!
The September security patch has been merged! Thanks to @jackeagle for the merge 🙂
Added toggle for carrier group visibility
Added support for MiSound FX and DiracSound FX
Improved lockscreen nav Pulse
Added music card in volume panel
Added centered R-style notification headers
Added ambient screen Pulse
Added volume plugins
Added toggle for gradient background in QS panel
Added setting to add minimum auto brightness value
Face authentication now automatically blocks when the device is in a pocket
Clicking on the QS data usage toggle now opens the data panel
Aligned music card vertically to volume panel
Added option to force custom Doze brightness
Made ringer icon optional in volume panel
Asus Longshot is now the default screenshot system!
Moved Dark Mode to Blissify Settings
Added dependencies to system themes
Fixed “Edit QS panel” icon touch issue
Fixed battery QS tile icon not changing. The detail for it was also removed.
Fixed “remove lockscreen default shortcuts”
And that’s it for this month! Have a good one and see you in the next update post!
For the longest time, the Android-x86 world has been plagued with not having a proper recovery toolset packaged with the OS. There have been a few attempts at such a solution in the past, but nothing that was able to coincide with the main Android system and work together. Until Gearlock came into play. It started as a toolkit to do many of the underlying troubleshooting within a basic UI for Phoenix-OS, Remix-OS, etc. And by working together with the lead developer, Axon, we were able to work out a solution for all Android-x86 based projects. Just clone vendor-gearlock into your AOSP based project, run one command, and it’s ready to go. The result is a recovery/tweaking solution that can be run along side system, and also acts as a pre-bootloader for the main OS, so you can in fact choose to boot into Recovery first if you desire.
Here’s a little preview I tweeted, giving a quick glance of some of the options available.
We’ve also been further integrating more and more ROMs into Android-Generic Project, Lineage OS 17.1 being the latest. And boringdroid developer, @utzcoz (Also the newest member of Team Bliss!!!) has also been hard at work in the Android Desktop UI development world, so we’ve been mostly testing all the changes under the hood there with the recent Lineage OS test builds, but have plans on continuing the ROM bringup game soon.
Again, if you are interested in learning more about Android-Generic Project or Android-x86 development in general, be sure to check out our project readme. It has quite a few learning resources as well as plenty of documentation on the process.
And as a gauge of interest, we would like to know how many of you out there would be interested in watching the entire bring up process for a ROM, maybe streamed on Twitch someplace we could interact with those watching, and if so, what ROM would you all like to see added? Let us know in the comments below.