Articles · EJ's Wonder Emporium

Changing the landscape

Fri, 16 May 2025 13:11:00 +0500

How It Started

Back when I first started the BlissLabs nonprofit, I knew it had the potential to help transform the Android ROM scene at the time, so in my mind, it would be well worth the effort. What I didn’t know back then was exactly how it would do that.

At the time, I knew we needed to set up a way for the teams to collect funds, provide services like servers, design, and others, and make sure that it was not something only one person controlled. So setting up an org with a board and bank account was a must, but what kind of org was the question.

With my previous experience with my wife and her work with the Pediatric Hydrocephalus Foundation, I learned a lot about how that organization works, and how it relies on volunteers to advocate for Hydrocephalus, as well as what that advocacy looks like when it comes to lobbying. I could also see how an org for open-source Android projects could run on a similar structure. So I incorporated BlissLabs as a 501c(3) nonprofit organization, and all the leaders across the Bliss projects all voted on a board, which would have distributed control of the organization’s infrastructure.

The next steps were to get each project to assign a lead and form a way to not have just the board members calling all the shots, and let the board focus on stuff that the nonprofit would need to help the projects underneath it succeed. So we went into research mode and found a number of grants that helped supply emails, servers, documentation and planning services, and more, and distributed access to those across all the individual projects. This also included signing up for more notable donation collection methods as well, like OpenCollective, where we were in a unique position to sign on as a fiscal host, and let each project under BlissLabs set up an account and use BlissLabs as the host.

How It Changed

This is about the point where we decided to branch out, and promote what we did so other projects could benefit from it. This initially brought in community projects like Bliss-x86 (now Bliss OS), Boringdroid, SupremeGamers, and later led to Waydroid, SmartDock, XT-Mapper, IzzyOnDroid, Lindroid and others. With the majority of these projects utilizing BlissLabs as a fiscal host and a talent pool or think tank for ideas and innovation.

This eventually led to us also finding a way to tap that talent pool for others outside our org too. After being approached by a few companies wanting to have Android work done for them, we decided it was also time to start a separate for-profit company, Navotpala Tech (Bliss Co-Labs), that would be able to be insured, provide the means to manage incoming contracts, and empower the individuals that contributed to the many projects underneath the BlissLabs umbrella. Closing the loop for individuals looking to start off by learning through contributions towards our projects, and ending with paid opportunities for those individuals that showed a track record of dedication, innovation and lack of ego.

Where We Are Headed

This is where we are today. Two organizations, working together to cultivate innovation and bring to it products across the world. Working in a way that contributes heavily to the open-source ecosystem at the same time. And this is where I will set up the next stages of this vision too.

For the future of BlissLabs, we need to grow now. The nonprofit will need community organizers, content creators, grant writers, web designers, management, and a number of other positions added in order to facilitate the growth needed for the projects it has now, and the projects that will join in the future. And together we can all change the landscape to allow growth and monetization opportunities where there was never any clear cut way for all projects to grow, or these people to make a living doing what they love to do.

For the future of Navotpala Tech, in order to make sure that company stays true to its mission and vision, it is hard to find an exemplary solution when money is involved, and businesses often prioritize profits over ethics. Because of this, we have decided to continue on the slow growth road, letting small parts of each project help fund the businesses R&D budgets, and other initiatives that will expand the product line and fortify the company’s infrastructure. This will allow it to have the largest potential impact on the talent from BlissLabs projects, and give more than just a few core people a chance at contract development & design work. The business will still also continue to contribute directly to open-source development in order to help set an example for other businesses to know what a healthy CSR plan could look like.

Bass OS - when the bass drops, the music gets better

Wed, 13 Mar 2024 12:32:00 +0500

Project Background

About a year ago, I was contacted by a number of companies that wanted their own Android for PC OS that they could control the access and redistribution rights to. So I started on a journey putting together a new form of Bliss OS for the same kind of devices but done a little differently in order to target businesses, and product use, but was put together in a way that would allow me to retain rights to the parts that apply to all devices (the generic bits). When I first got started, the goal was to make one source have as many features as possible without the use of proprietary components like Google Play Store, Widevine, etc., and then just enable/disable various features and options for specific use cases. Around April of 2023, that goal was achieved and I had a solid starting point for the source that opened up many of the tiny little changes required for device and application specific use, and brought it all together with a single build toolkit. This at least set the stage for the bare minimum needs, and shed light on the future challenges for the project.

Challenges

The project updates would have to have the following goals, and those had a few challenges attached:

Make that system easy to expand:
I used a system that allows developers a simple method for expanding on the available build options and configuring the source all from the command line. Learning lessons from my previous projects like Android-Generic Project, I also wanted to include a way to make things easily upgradeable to new versions of Android. So this system had to include some of the advances to the patching system used in AG.
Make the system build process accessible for others:
I expanded the Bliss OS source and created new tools that greatly simplify the process and provide the majority of the configuration options through a single interface. This allows developers to easily setup, configure and deploy their generic Android .iso’s with little effort.
Reserve a place for private patches, addons, etc. for companies:
Some companies and developers aren’t able to share things as open source, so I need to take that into account and provide a way for them to naturally separate what should be a generic change and what should be a private change. So I added a few places for companies to add their changes and have them automatically apply when the source unfolds.
Reserve a place for the most valued assets to easily be integrated into the system:
I have many changes that don’t really fit in the “generic device” category, like password protected admin access, kernel level changes to guard against unwanted wireless devices being plugged in, etc., so I wanted to still offer these specialized changes to companies that had a need for them. The way I do this is through licensing addons (features). Each addon will come as its own separate project that gets linked inside the main bass-os project folder as an addon, patchset or manifest. This covers prebuilt pro versions of our apk’s, sources for API’s and packages, and individual changes to be placed on-top of the source.

Looking at what the community and industry have put together for Raspberry-Pi builds on Glodroid, Glodroid-Community and Tesla-Android, I was able to take inspiration from how they have things setup, and apply those concepts to Bass OS. This resulted in a single repo setup that developers and clients can easily manage, while retaining the ability to separate our private addons and features, and give developers a way to include their private changes as Ill. All while automating the process down to just a few keystrokes.

For those that are curious, I detail a little about the toolkit on our Website for Bass OS (https://bliss-bass.blisscolabs.dev), along with a glimpse of the many use-cases and applications for using an OS put together like this.

Licensing

The largest challenge I had for this project was related to ego. How do I create a product that is as easy to adopt and maintain as an Open-Source project, while still retaining the ability to generate income from it? This is where the licensing system comes into play. For many of the parts of this system, there are addons and features available. For the build system, we include the base “generic” options and scripts as part of the open-source project, while we reserve the “value added” bits for licensed use. And any parts of those two sides that cross over, should have a warning or error attached when they are used without licensing access to the change first.

Taking this approach will still allow us to provide companies, hobbyists, and individuals a free to use set of features, apps, and configurations, while attempting to force licensing onto those that would want to change the source and rebrand without properly licensing. Because innovation through open-source is only viable when we all play by the rules.

Sources & Documentation

Now we can get to the exciting part of this post, the source code. You can find the source at the following link: https://github.com/Bliss-Bass/bass-os but please pay close attention to the readme for that repo, as it contains all the required information to get things up and rolling. Including dependencies, hardware requirements, resource links and more.

I plan on creating addon guides & templates, contributing guides, and linking the various feature guides we have on Bliss OS docs that they have adopted for some of their builds. This should allow the community everything they need to build off our open-source offerings and set their own terms for licensing their creations if they choose to do so.

Gratitude

I do want to say Thank You to all the members of the business and user community that have helped the growth of this project. And I am looking forward to 2024 being a great year for Android on x86 based hardware.

Android, AOSP, and what Open-Source Licensing means for you or your company

Fri, 13 Oct 2023 12:32:00 +0500

Android is one of the most popular operating systems in the world, powering billions of devices. It is based on the Android Open Source Project (AOSP), which is a free and open-source software platform. AOSP is important because it allows anyone to modify and redistribute the software, which has led to a wide variety of Android devices and applications.

One of the key features of AOSP is that it is using open-source software (OSS) components licensed under the GNU General Public License (GPL), LGPL, MIT, BSD or Apache License. Some of these licenses require that the source code for any software that is based on AOSP must also be released under the same license. This ensures that users can inspect the source code for security vulnerabilities and make changes to the software to meet their specific needs.

In this post, we will discuss the importance of following through with the GPL source requirements for AOSP. We will also provide some tips on how to evaluate the security of software that is based on AOSP.

The Importance of Releasing Changes to the Source for AOSP

There are several reasons why it is important to follow through with the GPL source requirements for AOSP.

First, it ensures that you are complying with the licenses of all of the open source software that you use in your product. When others can trust that you are releasing any updates made, your product image is improved and you build further confidence with your user base.

Second, it helps to ensure the security of the software. When the source code is available, anyone can inspect it for potential security vulnerabilities. This can help to prevent malicious actors from exploiting these vulnerabilities to attack users.

Third, releasing the source code can help to improve the quality of the software. When users are able to contribute to the development of the software, they can identify and fix bugs that the original developers may have missed. This can lead to a more stable and reliable software.

Fourth, releasing the source code in its entirety can help to promote innovation. When developers are able to build on the work of others, they can create new and innovative software applications. This can lead to a more vibrant and dynamic software ecosystem.

What You Should Look For When Projects Do Not Produce Source That You Can Inspect

When an AOSP based project does not produce source code that anyone but them can look through, it is important to be wary. There are several reasons why a company might choose to do this, and we will touch upon the nefarious reasons first.

They may be hiding something malicious. If a company is not willing to release the source code for their software, it is possible that they are hiding something malicious. This could include malware, backdoors, or other security vulnerabilities.
They may be trying to lock you in. If a company does not release the source code, they can control how you use their software. This could mean that you are not able to make changes to the software, or that you are required to use their proprietary services.
They may be trying to make a quick buck. Some companies will release closed-source software that is simply a repackaging of open-source software. This allows them to charge a premium for software that is actually free or was not properly licensed for commercial use.

If you are considering using an AOSP based OS solution from a company that does not release the source code, it is important to do your research. Make sure to read reviews and security reports before making a decision. You should also be prepared to pay a premium for the software, as there is no guarantee that it is safe or secure.

If you are looking for an Android project that you can be confident in, it is important to choose a project that publishes its source code. This will help to ensure that the project is secure and that it is committed to quality.

What Can Make This Easier?

The importance of releasing source code based on AOSP cannot be overstated. AOSP is a cornerstone of the Android ecosystem, and it allows anyone to create and distribute their own version of Android. This freedom has led to a wide range of innovation, from custom ROMs to new devices and operating systems.

However, with this freedom comes responsibility. When you release a product based on AOSP, you are legally obligated to comply with the licenses of all of the open source software that you use. This can be a complex and challenging task, especially if you are not familiar with open source licensing.

Releasing source code based on AOSP is important for a number of reasons:

Compliance: It ensures that you are complying with the licenses of all of the open source software that you use in your product.
Transparency: It allows the community to see how you have used AOSP and other open source software, which can help to build trust and encourage collaboration.
Security: It can help to improve the security of your product by allowing others to review your code and identify and fix vulnerabilities more quickly.
Innovation: It can foster innovation by making it easy for others to build on your work and create new and innovative products and services.

Android-Generic Project Manager’s Auto OSS License Documentation tool can help you to comply with the licenses of all of the open source software that you use in your AOSP-based product. This tool can automatically scan your repo based code for OSS licenses and generate a manifest that documents the licenses and any required actions. This tool can be a valuable asset for any company that is releasing AOSP-based products.

In short, releasing source code based on AOSP is a good thing for everyone involved. It helps to ensure compliance, transparency, security, and innovation.

Conclusion

In this post, we have discussed the importance of following GPL source requirements for AOSP. We have also provided some tips on how to evaluate the security of software that is based on AOSP as well as provided a solution to assist in properly maintaining projects based on open-source code..

When choosing an Android project, it is important to take a hard look at the project’s security practices. One of the most important things to consider is whether or not the project publishes its source code.

If you are considering using an Android project that does not publish its source code, it is important to be aware of the risks. There is no way to know for sure whether or not the project is secure if the source code is not available. It is also important to be aware that the project may not be committed to security if they are not willing to publish the source code.

Here are some additional tips to help you evaluate the security of an Android project:

Make sure the project is licensed under the GPL, LGPL, BSD, MIT or Apache. This will ensure that the source code is available for inspection.
Read reviews and security reports. This can help you to assess the quality and security of the software.
Be skeptical of claims of security without proof. If a company claims that their software is secure, but they do not provide any proof, it is important to be skeptical.
Ask for a security assessment from a third-party security firm. This can help you to get an independent opinion on the security of the software.

By following these tips, you can help to ensure that you are using safe and secure Android software.

Building your own business through task automation

Sun, 07 May 2023 12:32:00 +0500

The importance of Task Automation

Task automation is the process of using software to automate simple tasks or a series of more complex tasks. This reduces the need for manual handling of such tasks, therefore improving accuracy and efficiency. Once configured, tasks are completed automatically, allowing more time for employees to focus on creativity and strategic workflows.

How to Automate Tasks

There are many different ways to automate tasks. Some common methods include:

Using software robots (bots) to perform repetitive tasks
Creating macros to automate tasks in a spreadsheet or other software program
Using workflow automation tools to automate processes that involve multiple steps

The Benefits of Task Automation

The many benefits of task automation include:

Increased productivity: Task automation can free up time for employees to focus on more creative and strategic work.
Improved accuracy: Task automation can help to improve accuracy by reducing the risk of human error.
Enhanced efficiency: Task automation can help to improve efficiency by streamlining processes and eliminating unnecessary steps.
Reduced costs: Task automation can help to reduce costs by eliminating the need for manual labor.

How to Get Started with Task Automation

If you are interested in automating tasks in your business, there are a few things you need to do to get started:

Identify the tasks that are most suitable for automation.
Choose the right automation tools.
Develop a plan for implementing automation.
Train your employees on how to use the new automation tools.
Monitor the results of your automation efforts and make adjustments as needed.

How I Automate Tasks in my Development Environment

Throughout my professional career, the companies I have founded have all stemmed from observing an existing need, and recognizing my ability to fill that need. Be it web design, application development, or software automation, my companies were also all established as partnerships. This collaboration allowed me to provide value to the client while collectively sharing responsibilities.

As time goes on, responsibilities can shift and the levels of efficiency and productivity can change. As usual, I answer the phone calls, I respond to the emails, I lead the efforts in sharing what the business is all about. In addition, for my current company I am also the primary developer which my clients are seeking to have working on their projects. The successes and experience gained through my previous companies have helped to establish myself as one of the top engineers in the field, intimately familiar with the software and hardware stacks being used.

This is where I start to let my creative juices flow a bit. The more effort spent on tasks “X”, “Y” or “Z”, the more I am able to identify the portions of those tasks which are repetitive. At this point I am able to mitigate this repetitiveness by utilizing existing automation tools or by creating new tools from scratch for these specific tasks. This results in a very lean infrastructure for a business. This form of task automation allows me to be more creative and focus on exemplary solutions for my clients and the community, instead of solutions that can bring a quick buck.

Task Automation in Development

When it comes to task automation in development, normally the mindset required does not come naturally. Meaning not everyone can easily recognise that they have performed the same steps in a process 3 times in a row. Their focus is on the task itself, not the process in which to complete it. To find this process, you must also record or note each step taken to complete the task/s.

For example, when working with Linux and AOSP development, 90% of the steps one takes are already recorded by default in a hidden file in the user’s “/home” directory. Check for a “~/.bash_history’’ file and it will contain all the commands entered into the terminal for that user’s bash sessions. Scrolling through the lines of commands recorded, we can begin to spot the repetitive commands which keep repeating. Those lines can be copied out into a separate notepad/.txt file for now, including a comment about the task it relates to.

After scrubbing through the history looking for patterns, there will be an arsenal of repeated steps, start looking at each task and establish variables from the parts that change. This allows us to start building small functions that can handle these variables (Example: do_taskname $1, $2, $3, $4, etc.). Building out functions to take specific inputs can also help take the work out of a lot of things that just take time away from creativity. Especially when we start to tie those functions together into something usable.

In AOSP, we still use a “vendorsetup.sh”. This allows us to build a “vendor profile” or use one that already exists in the project, and add the common functions there. Or if you are like me, you tie those functions together with a menu or a UI, and lock the user into the process they should follow.

An alternative route one could take when looking for ways to automate things in software and engineering, is to also look for others that thought of it first. This is where tools like the “Android-Generic Project” come into play.

Very often, when you see a need for a solution somewhere within your workflow, someone else also saw that need and already started working on a solution. My recommendation for places to look for such solutions include: Bitbucket, GitHub, and GitLab. There are of course other options though, you just have to keep your eyes peeled.

For your company, you have the unique knowledge and details of what you or your team’s workflow consists of.You have now equipped yourself with the knowledge of what to look for in order to make things easier, accurate, and efficient!. Get out there and start automating your work tasks. You can thank me later ;)

Conclusion

Task automation is a powerful tool that can help businesses to improve productivity, accuracy, efficiency, and cost-effectiveness. If you’re not already automating tasks in your business, then what better time than today to consider the benefits and get started?

Here are some important tips to help automating tasks in your business:

Start small. Don’t try to automate everything all at once. Start by automating a few simple tasks and then gradually add more complex tasks as you become more comfortable with automation.
Be patient. Automation can take some time to implement and get up and running. Don’t get discouraged if you don’t see results immediately. Just keep in mind that the efforts going in will lead to the improvements to the business in the end..
Be flexible. As your business grows and changes, you may need to adjust your automation strategies accordingly. Be prepared to make changes as needed.
Get help if you need it. There are many resources available to help you automate tasks in your business. If you get stuck, don’t hesitate to ask for help from a consultant or other expert.

If you would like to check out some of the task automation I have been using in my profession, feel free to head over to Android-Generic Project (https://android-generic.github.io). If you feel your AOSP based project could use an automation mindset to help make things easier on your engineering department, please checkout the Bliss Co-Labs (https://blisscolabs.dev), as that is kind of what we’re here for.

I hope you found this blog post helpful. If you have any questions, please feel free to leave a comment below. And if you know someone else who might find this information helpful, please share it with them.

A Return To Bliss

Fri, 24 Feb 2023 16:20:00 +0500

What Happened

It’s been a minute… but it’s been a very valuable minute to say the least. So what has been going on? Let me fill you in.

Last we checked-in, I was heading off to work for Esper, doing what I love to do. I got a chance to learn more about their projects, help them expand hardware support and fix a few issues. I even got the chance to learn how businesses have been working with Android and AOSP. Overall, before becoming part of their recent round of layoffs in January, I felt I had a solid impact on Esper’s future, and hope that some of the plans laid out together allow them a successful future in the market.

When one door closes, another one opens

I have always been the optimistic type, to a fault at times. So the week I was laid off, I was already being contacted by companies looking to get some work done for bringing Android to their x86 based devices. So I took that as a sign for what’s next, and started to plan out the business plan for Bliss Co-Labs (take 2). This time, not only as a software development company, but as a contract development and consulting company too. Since it seems the niche is Android-x86 work, might as well try and fill the need I see, right?

So I’ve filed Bliss Co-Labs as an S-Corp, so the company can take on these contracts, and divide up the work based on each team-members specialties. My goal is to still be involved in every project, but I am planning on helping everyone learn the magic of Android-x86 in the process. This will also extend to the customers too, as the company is offering a collaborative contract development service, where we will work with their engineers to help them learn how to work with Android on x86 or Android on Linux, and also license the use of our shiny new tools (shameless plug for the new version of Android-Generic Project coming out soon).

Back to my Blissful roots

Overall, I see what has happened over the last two months to be a godsend, allowing me to follow my passions, and not in a way that is geared towards making the largest possible profit, but in a more Blissful way, planning the exemplary route that would benefit the most users at the same time. So when customers need their proprietary bits to stay private, we can do that, while allowing the structure we build to support those proprietary bits, the ability to benefit the next customer behind them.

What about BlissLabs

The plan for BlissLabs is to stay running as a 501(c)3, and continue as the non-profit it has been, since that company has seen growth and reach spread further each year, we don’t want to spoil things for that momentum. This was another reason I decided to start the S-Corp as a separate entity from BlissLabs, using my own funds. So what we do through Bliss Co-Labs does not conflict with that organization at all.

Our intention is to provide the customers with a way to work with our open-source projects, while creating in-house solutions that the customers can use themselves to help automate the process further. So yes, if the plan works out in the end, we would have created the robot that replaces our jobs. But we would have also created the solution that allows us to move on to bigger and better ideas for the community, and implement those much faster.

A State Of Bliss

Tue, 19 Apr 2022 16:20:00 +0500

The Backstory

Bliss has been a part of my life since 2012/2013. I had initially started as a graphic designer with Team Bliss through kbell, a developer on XDA that was maintaining the tablet I was using (Galaxy Note 10.1 I think), and I was very much a noob trying to help the community with answers to their questions. I eventually met the rest of the team, just after they had split from Beanstalk ROM, into a new team, Bliss ROM.

This team was so much more helpful in my learning how to work with Linux and Android source than any of the famous guides their members have produced over the years ever have been. They cared about the teammates first, then the product of that teamwork second. That mentality helped to foster some great ideas as other projects started from members of the team, such as Nicholas Chum’s, Substratum, and a few other projects due to our open discussions about technology and the future potentials of Android.

The first few years of working with Team Bliss was a blast, with many successes as well as drawbacks. Noticing how a majority of the issues we were facing on the team were due to conflict of opinion or bad judgment when it came to direction, we decided to decentralize how the team operated and how our infrastructure worked. That is where I got the initial vision for starting a non-profit 501c(3) organization to take over the tasks of worrying about the “how” in keeping the team running, and let the team members focus on what they enjoy the most. This was how Bliss Family of ROMs was born, and has since been renamed to BlissLabs. This non-profit allowed our team to grow into many teams with very different projects, but they all shared Android, Linux and treating eachother as family at the core.

Accomplishments within the team

I initially started off on the team learning as much as I could, and eventually started the BlissRoms-x86 project (Bliss x86 for short). I based it off what I learned by picking through the Android-x86 projects source commits. While maintaining Bliss x86, I also joined the Android-x86 team, and we all started working together, but still keeping projects separate, while cross promoting each other’s work, and helping in each other’s community.

Over the following years, we offered the active members of Android-x86 project a space on our Slack server, access to Android build servers, and together we grew, attributing our work to Android-Generic Project to make things easier to work with for the community, and the patches refined from there, back into Android-x86 project when ready.

This move has allowed us to continue development on Android-x86 project past Android 9, and into Android 10, 11 & 12, and allowed Bliss OS 11, 12 & 14 to act as the testing ground for all the experimental changes that had the potential to wind up added to the Android-x86 project, while helping to provide all the test cases needed to automate the processes, patchsets, and customization options, and wrapping them up into Android-Generic Project.

This is where we started having an even greater impact on the community, allowing other ROMs an easier way to apply the work we’ve done onto their projects and benefit from it. This is what helped bring Project Sakura and a few others to PC’s, and provided the base for the Android 11 release of Prime OS. We also started working on a web based (Django) frontend for what Android-Generic Project was doing through terminal and Linux GUI, and automate it for users through a frontend web UI.

Then Waydroid hit the scene, I also saw a need to help on that project, so I dove right in, reworking the patching system to be more like what Android-Generic Project was using and organizing things to work better for x86 & x86_64 targets, as well as make it compatible with other ROMs, including /e/, Bliss & Project Sakura. We also ended up adding Waydroid target support to Android-Generic Project, since it fit neatly within that project’s vision for Android on all hardware. Waydroid also shared quite a few things under the hood with Android-x86, so the work there wasn’t too different. The work we did through Waydroid was an instant hit with the community, and allowed BlissLabs the ability to Level Up its ability to help the rest of the community by becoming a fiscal host on Open Collective.

What’s Ahead

Along this path I have been on with BlissLabs, a few companies have started to approach me and ask for my assistance in their projects which either work with my previous efforts, or use very similar methods to get their own work done. I have always given each one a conversation, my time and thoughts. Recently though, one of these companies, Esper has made an offer that would help not just my family and my personal life, but it would also provide more resources for running BlissLabs and supporting the future of Android on x86 development.

The only downside is that I would have to give up code contributions to Bliss OS, Android-x86, Android-Generic Projects, and others, while enabling me to continue managing the projects, but not contribute code towards them. While I was conflicted about this idea, I have to also take the time to recognise that I have reached a point where I have very few options available to me where I can turn to and learn from in the open-source community. I feel that further progress in the Android Desktop vision needs experts that just aren’t available to the FOSS community. Working with Esper could allow access to such experts, and also allow access to other learning opportunities that I do not have available currently. So, while the decision was difficult, I have decided to sign on with this company and continue my future work on Android for x86 platform from there.

What does that mean for BlissLabs and the projects? Well, you can expect the next few months (or longer), to be quite the transition phase. We are looking for new volunteers who would like to help in the development of all of these projects, and more.

With me leaving the coding side of these projects, it is making room for the great minds of @jackeagle, @hmtheboy154, @axonasif, @utzcoz, @erfanoabdi, and others to take over. I will focus on my leadership skills and hopefully fine tune a future vision of the Android on PC’s that we’ve all loved working on so far.

Don’t worry about BlissLabs, or the future here. The universe has a way of working things out for those that stay true to their dreams, and I know I haven’t given up on mine yet. :)