Install μlogger on CentOS 7 Server

If you are unfamiliar with μlogger, it is a handy Android application paired with a self hosted server application to keep track of your location. Or, in the author’s own words:

μlogger (‘micro-logger’) is an application for continuous logging of location coordinates, designed to record hiking, biking tracks and other outdoor activities. Application works in background. Track points are saved at chosen intervals and may be uploaded to dedicated server in real time. This client works with μlogger web server. Together they make a complete self owned and controlled client–server solution.

You can actually just use the app on your phone to record yourself walking, biking, flying, etc., and then save your track as a gpx file for editing or viewing on any supporting app on your phone. But, if you wanted to save your adventures easily, or keep your adventures updating live for someone you know to view, then you can use the web server application as well. It works incredibly well, and if you are out of cell/wifi range, it will update with your personal server once you return, which is very useful.

The only problem was, while it had clear instructions for installation, they were written for someone smarter than me, so it took a bit of work to get it set up on my home CentOS 7 server. Hopefully, by writing this down, others can save themselves a little bit of a headache.

First, I would like to mention that this assumes you already are running a web server on your machine. In my case, I am running the Apache web server. So, I wont cover web server installing and setup here, but there are some great tutorials for that out there, like this one.

The instructions look like this, per the

  • Download zipped archive or clone the repository on your computer
  • Move it to your web server directory (unzip if needed)
  • Fix folder permissions: uploads folder (for uploaded images) should be writeable by PHP scripts
  • In case of development version it is necessary to build javascript bundle from source files. You will need to install npm and run npm install and npm run build in root folder
  • Create database and database user (at least SELECT, INSERT, UPDATE, DELETE privileges, CREATE, DROP for setup script, SEQUENCES for postgreSQL)
  • Create a copy of config.default.php and rename it to config.php. Customize it and add database credentials
  • Edit scripts/setup.php script, enable it by setting $enabled value to true
  • Make sure you have a web server running with PHP and chosen database
  • Open http://YOUR_HOST/ulogger-server/scripts/setup.php page in your browser
  • Follow instructions in setup script. It will add database tables and set up your μlogger user
  • Remember to remove or disable scripts/setup.php script
  • Log in with your new user on http://YOUR_HOST/ulogger-server/
  • You may also want to set your new user as an admin in config file.
  • Folders .docker/ and .tests/ as well as composer files are needed only for development. May be safely removed.

The biggest headache that I ran into was that the minimum requirement was for PHP 5.5, and CentOS 7 only comes with PHP 5.4 by default. However, that was easily fixed as root:

yum update
yum install
yum install
yum install yum-utils
yum-config-manager --enable remi-php55 [Install PHP 5.5]
yum-config-manager --enable remi-php56 [Install PHP 5.6]
yum-config-manager --enable remi-php72 [Install PHP 7.2]
yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo

This updated PHP to version 7.2, so you could skip that line if you didn’t want it, but I figured it might save me from having to update it in the future, so I went with it. Note that I did have to test out my other server functions that use PHP to make sure they were compatible.

After getting PHP up to date, I then downloaded the μlogger server repository from GitHub. It is pretty small, and only took a few seconds, even on my slow 10 mb internet to download it. I extracted in place, and went to work in the terminal, moving it to my web server location and giving it the proper ownership:

cd Downloads/
cd ulogger-server-master/
mkdir /var/www/html/ulogger
cp -Rav ./* /var/www/html/ulogger/
cd /var/www/html/
chown -R apache:apache ./ulogger
cd ulogger/

Now that it is in the right place, I needed a database for it to work with….

mysql -u root -p
enter password:
MariaDB> create database uloggerdb;
MariaDB> grant all privileges on uloggerdb.* TO 'EDITED_USERNAME'@'localhost' identified by 'EDITED_PASSWORD';
MariaDB> flush privileges;
MariaDB> exit

Keep in mind, the author of μlogger only suggests a few privileges, which he states in his read me as “(at least SELECT, INSERT, UPDATE, DELETE privileges, CREATE, DROP for setup script, SEQUENCES for postgreSQL)” however, as I monkeyed around with this, the script only seemed to run when I gave my user all privileges. Not sure if that’s just me, but here’s what I did, and praise God, it worked, because I was getting a little frustrated at this point. This write-up is the end result, not the “how many times I failed setting this up” story….

Now I needed to proceed and make a copy of the config file and edit it per the instructions:

cp config.default.php config.php
nano config.php
cat config.php 

/* μlogger
 * Copyright(C) 2017 Bartek Fabiszewski (
 * This is free software; you can redistribute it and/or modify it under
 * the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3 of the License, or
 * (at your option) any later version.
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * General Public License for more details.
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, see <>.

// This is default configuration file.
// Copy it to config.php and customize

// Database config

// PDO data source name, eg.:
//$dbdsn = "mysql:host=localhost;port=3306;dbname=uloggerdb;charset=utf8"
//$dbdsn = "mysql:unix_socket=/tmp/mysql.sock;dbname=uloggerdb;charset=utf8"
// pgsql:host=localhost;port=5432;dbname=uloggerdb
// sqlite:/tmp/uloggerdb.db
//$dbdsn = "uloggerdb";
$dbdsn = 'mysql:dbname=uloggerdb;host=';

// Database user name
$dbuser = "EDITED_USERNAME";

// Database user password
$dbpass = "EDITED_PASSWORD";

// Optional table names prefix, eg. "ulogger_"
$dbprefix = "";


The key part that went wrong here, was that there were several examples of how to set the “$dbdsn” or database name and location. I tried the ones included in the file, but none of them worked, so I web searched and found this line worked: $dbdsn = ‘mysql:dbname=uloggerdb;host=’; so that is what I used in the end, instead of any of the included examples.

Now I needed to enable the setup script:

nano scripts/setup.php 

.... edited for space ....
// This script is disabled by default. Change below to true before running.
$enabled = true;
.... edited for space ....

With the setup script enabled, it was now time to get started! I opened https://EDITED_HOST/ulogger/scripts/setup.php page in my browser, and followed the on screen instructions, logging in with the username and password I made earlier, and everything went smoothly! Keep in mind, once the setup is done, you need to delete or disable the setup script to prevent it’s future use. So I just deleted it. Here is the end result when you bring up the web page https://EDITED_HOST/ulogger/

Sorry, I blurred everything out because I didn’t want any uninvited house guests! 🙂 If you want to see a great demo of it from the author, though, you can check it out from his web server on Heroku. Here’s a screen shot of it:

The mobile app is very simple to setup. Under settings, you simply input the username, password, and URL for your web server. You can then choose if you want it to auto upload as you go, or you can update it manually by pressing an upload button on the main screen.

I thought it best to mention that the original user you make is an administrator, and can edit several settings. I recommend that you make a new user with lesser credentials (non-admin) for use with the phone app. When you are logged in as the administrator (the first account you made) you can choose to make new users. This allows you to have lesser accounts for daily logging of activity. It also is handy if you are using this for your company as a way to track drivers/workers or if you have multiple family members, because everyone can have their own username and password.

Hopefully, this will save others using CentOS 7 a little bit of time to set this up!

Linux – keep it simple.

Ship, Captain, and Crew: Ready to set sail!

Well, for better or worse, it’s finally finished! That’s right, my first, from scratch, no tutorial, 3D dice game, “Ship, Captain, and Crew” is now in Beta stage! Be sure to give it a try!

You can find all the source code here:

And you can download the Windows, Linux, and Android versions here:

Be sure to let me know in the comments if you find any bugs or have any suggestions. The game is not really for playing by oneself, although there is a player vs computer setting. However, the key point of this game is a sort of paper/rock/scissors game with your friends when you need to decide something, like who’s buying, or who gets to pick where/what/etc. next.

You can also read the official rules on Wikipedia, which my game follows. I mention this, because some play where you must roll a 4,5, then 6 for ship, captain, and crew, and others play 6, 5, then 4 instead. Either way, the mechanics of the game are the same, just which order you must roll the dice. In this game, I set it to follow the official 6, 5, and 4 rule-set.

Let me know if you tried it out!

Linux – keep it simple.

Ship, Captain, and Crew: Cross Platform Differences?

Hopefully, the above pictures came through for you, or this wont make much sense. I’ve been working on my dice game, and it is nearly completed. However, as I test it out on different platforms, I notice that it doesn’t look the same. In the above screen shots, the left is from my Linux desktop, and the right is from my Android phone.

What hopefully is obvious is that the Android phone has an abnormal pixelation/black dots on it. Also notice that the table and dice are brighter on the Linux machine. Both screens are using a 1920×1080 resolution, so it isn’t a stretch/scale problem. The darkness of the Android screen is not a display brightness problem, as these are screen shots and not pictures of the screen. So what is causing this?

Well, after a bit of web searching, I came up with nothing. Thus, I must be using the wrong key words. But, after some trail and error, I found that the culprit was the texture normals for the table. Interesting. As far as I can tell, the normals are used to calculate light beams reflecting/refracting off of the surface of the object. For some odd reason, the normals texture overlay work great on the computer, but fail miserably on the phone. But both phone and computer support openGL 2 and 3, and this game is only openGL 2.

So, I don’t know why it happens. If you happen to know, please feel free to let me know in the comments. What I did to fix it was remove the normals texture overlay, and just use the textured wood overlay for the table. Now both the phone and the computer look the same. As always, you can check out the full project on my GitLab.

Linux – keep it simple.

Ship, Captain, and Crew: Exports and keys


So, as I near completion of my 3D dice game, I ran into several small issues that I thought I would share here, since they all apply to exporting your game. Of course, as you go along, if you are making a cross platform game, you occasionally need to export it and test various things on the different platforms (more on that in another post). And when you export them, you have to use this export function and templates.

So, that said, a few interesting tid-bits:

First, I found it interesting that when you make a release key for your Android version of the game it saves your key password in a plain text file in your directory folder. Ordinarily, this wouldn’t be a terrible issue, except that as a maker of open source games, when I use git to sync my work, it then would save the release key in plain text on GitLab! So, if you are to the point where you stop using debugging, and start using release keys that you made or signed, you will have to do the following:

  • Open you project folder
  • Find the file called: export_presets.cfg
  • Find the line called: keystore/release_password=
  • and delete your password.

Or, you can delete your password from inside Godot, in the exports screen by scrolling down to it and deleting it and saving the project. I find this to be a bit annoying. I would think Godot would at least hash it, or something. Or keep passwords in another file, specific for Godot, and not in your project folder. But that’s just me, I guess.

Second, if you are making an Android version of the game, you will need an icon. By default, it uses the icon you already have for your game in the main project folder, called “icon.png”. But if you don’t specify an icon for the Android game, your main icon will come out looking wrong (way zoomed in) on your Android device.

After some reading, I found that you need to supply one 192×192 pixel icon, which Godot will then translate into the various other icon sizes. But, this didn’t work. I found out later that is because in Android 8+ you need 432x pixel icons. So, in all, you will need several icons, each used for different launchers. Or, carefully edit your main icon and it will be used in a fallback chain and edited by Godot to make your icon for the Android application.

Third, I ran into a lot of problems with key signing. I’d like to point out that in the guide it says that you set the debug key in the editor settings. This is true, and without that it will not work at all. That said, with that, it will not work at all either. At least for me. I had to also specify in the project export template for the Android app the paths to the debug keys again. Otherwise I got an error about “jarsigner” failing. Overall, this is only a minor inconvenience, but it was a big hang up for me until I figured it out. You then have to remove all of that and enter you release keys if you want to make a release version.

Just a few thoughts from a guy who doesn’t really know what he’s doing, so take it with a grain of salt. But, if you run into the above issues, be sure to try these out. Also, you can check out the full code for my game here on my GitLab.

Linux – keep it simple.

E Zygote : java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist


More dreaded whitelist errors! Essentially, an app is trying to do something it should not be allowed to do. You can see the logs here:

E Zygote : java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: { android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, android.permission.PACKAGE_USAGE_STATS, android.permission.ACCESS_FONT_MANAGER, android.permission.NAVIGATION_EDITOR, android.permission.FORCE_STOP_PACKAGES, android.permission.STATUS_BAR}

The funny part is, these apps are system apps, built in Resurrection Remix itself. That means that these errors are caused by the people who put RR together. Most likely, since it draws from LineageOS at it’s base, changes were made to LineageOS, and RR has not caught on yet. Either way, this is an easy fix, but will become a recurring problem.

In this RR rom, go to:


and open it up. If you search in this file for, you will find it listed there, with a few “whitelisted” or pre-approved, permissions.

<privapp-permissions package=”″>
<permission name=”android.permission.BIND_APPWIDGET”/>
<permission name=”android.permission.CONTROL_REMOTE_APP_TRANSITION_ANIMATIONS”/>
<permission name=”android.permission.GET_ACCOUNTS_PRIVILEGED”/>

Notice that the error said that the launcher needs “android.permission.STATUS_BAR” and it’s not on the list. So, you need to add it to the list, like so:

<privapp-permissions package=”″>
<permission name=”android.permission.BIND_APPWIDGET”/>
<permission name=”android.permission.CONTROL_REMOTE_APP_TRANSITION_ANIMATIONS”/>
<permission name=”android.permission.GET_ACCOUNTS_PRIVILEGED”/><permission name=”android.permission.STATUS_BAR”/>

Now you will have solved your problem. However, this might not be the best place to fix this. Another place that is more likely to be useful is in this file:


Or to make a privapp-permissions-rr.xml file.

In either case, the only issue with doing it this way is that every time you sync the repo, you will need to solve this issue again, and again, and again. So, you could take two alternative routes:

  1. Make an overlay file in your device tree and overlay these permissions.
  2. Make a pull request on the RR repo to fix the actual issue.

The second method is the best, because this helps everyone. It also clears up problems with overlay files when the original file does get fixed later. Either way, this will solve your problem.

Linux – keep it simple.

Finding the real errors in your Android logcat…

So, you built a rom, and something went wrong. It’s stuck at the boot logo, or it does boot up, but doesn’t do “xyz” action, or it crashes right after you get to the home screen. You’ve played this game before, you pull logs, and all you can see is line after line of errors. Where do you start?

This happens to me all the time. It can be really tough trying to figure out which error is the one that brought the system down, but there are a few key tips to help you unlock the real problem.

  • Look for the key phrases, like “beginning of crash”

Typically, this phrase is when things are going downhill fast. Oft, when things are at this point, the following data will repeat itself and may or may not be helpful, as it may or may not be able to finish writing down the issue. Typically, the lines just before and after this phrase are your biggest clue. Here’s an example:

08-14 15:55:22.357 1468 1468 E System : ******************************************
08-14 15:55:22.358 1468 1468 E System : ************ Failure starting system services
08-14 15:55:22.358 1468 1468 E System : java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: { android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, android.permission.PACKAGE_USAGE_STATS, android.permission.ACCESS_FONT_MANAGER, android.permission.NAVIGATION_EDITOR, android.permission.FORCE_STOP_PACKAGES, android.permission.STATUS_BAR}
08-14 15:55:22.358 1468 1468 E System : at
08-14 15:55:22.358 1468 1468 E System : at$100(
08-14 15:55:22.358 1468 1468 E System : at$PermissionManagerInternalImpl.systemReady(
08-14 15:55:22.358 1468 1468 E System : at
08-14 15:55:22.358 1468 1468 E System : at
08-14 15:55:22.358 1468 1468 E System : at
08-14 15:55:22.358 1468 1468 E System : at
08-14 15:55:22.358 1468 1468 E System : at java.lang.reflect.Method.invoke(Native Method)
08-14 15:55:22.358 1468 1468 E System : at$
08-14 15:55:22.358 1468 1468 E System : at
08-14 15:55:22.359 1468 1468 D SystemServerTiming: MakePackageManagerServiceReady took to complete: 514ms
08-14 15:55:22.359 1468 1468 E Zygote : System zygote died with exception
08-14 15:55:22.359 1468 1468 E Zygote : java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: { android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, android.permission.PACKAGE_USAGE_STATS, android.permission.ACCESS_FONT_MANAGER, android.permission.NAVIGATION_EDITOR, android.permission.FORCE_STOP_PACKAGES, android.permission.STATUS_BAR}
08-14 15:55:22.359 1468 1468 E Zygote : at
08-14 15:55:22.359 1468 1468 E Zygote : at$100(
08-14 15:55:22.359 1468 1468 E Zygote : at$PermissionManagerInternalImpl.systemReady(
08-14 15:55:22.359 1468 1468 E Zygote : at
08-14 15:55:22.359 1468 1468 E Zygote : at
08-14 15:55:22.359 1468 1468 E Zygote : at
08-14 15:55:22.359 1468 1468 E Zygote : at
08-14 15:55:22.359 1468 1468 E Zygote : at java.lang.reflect.Method.invoke(Native Method)
08-14 15:55:22.359 1468 1468 E Zygote : at$
08-14 15:55:22.359 1468 1468 E Zygote : at
08-14 15:55:22.360 1468 1468 D AndroidRuntime: Shutting down VM
——— beginning of crash
08-14 15:55:22.361 1468 1468 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main
08-14 15:55:22.361 1468 1468 E AndroidRuntime: java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: { android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, android.permission.PACKAGE_USAGE_STATS, android.permission.ACCESS_FONT_MANAGER, android.permission.NAVIGATION_EDITOR, android.permission.FORCE_STOP_PACKAGES, android.permission.STATUS_BAR}
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at$100(
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at$PermissionManagerInternalImpl.systemReady(
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at$
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at
08-14 15:55:22.368 1468 1856 V FontService: CurrentFontPreviewDir absolute path = /data/system/theme/font_previews/com.custom.fonts/Inconsolata
08-14 15:55:22.369 1468 1468 I Process : Sending signal. PID: 1468 SIG: 9

Other great phrases to watch for are:

  1. crash
  2. fail
  3. not found
  4. error
  5. fatal

Usually these phrases will be what you are looking for.

I highlighted the “beginning of crash” line in bold and underlined it to make it easier for you to read. Here we see that the preceding 20-ish lines and following 20-ish lines are all about how the system is struggling with a fatal error, because there are permission issues. (I’ll talk more about solving this next post.)

That’s fine and dandy if you have an actual crash, but doesn’t help if you just have errors in the log and something isn’t functioning correctly. Or sometimes you can have a crash, but there is no “tattle-tale” information that shows you what the problem is. You just start going back through all the “E” errors in the log trying to find one that is the culprit.

  • Compare your log to another to sort out minor errors.

This is not always a viable option, but it has been helpful for me in the past. For instance, recently I purchased an Xperia XA2 Ultra. It had a LineageOS Pie build, but no Resurrection Remix Pie, so I decided to make one. RR didn’t finish booting, but there were a lot of errors in the file, and it was difficult to pinpoint which one was the main culprit.

Take for example, this line:

E Sensors : sns_reg_conf_la.c(766):cei_project_id = BY25

Is it a big deal, or not?

So, I took a logcat of the good, booting, functional LineageOS Pie rom, and a logcat of the bad, not booting RR rom, and compared them with diffuse. Turns out that the above line is in both files, so it’s not too big of a concern right now (but I should fix it later).


This can be very tedious, though, as 28 thousand lines is a lot to sort through. Fortunately, Linux has some handy commands to help you with that. First, I cut the time out of the files:

$ cut -c31- linfirstbootedit.txt |tee linNoTime.txt
$ cut -c31- rrFirstBootedit.txt |tee rrNoTime.txt

Now I had the files without the time at the beginning, which makes them easier to sort. Then, I sorted them and compared them, pulling only the different lines.

comm -23 <(sort rrNoTime.txt) <(sort linNoTime.txt) > Just_rr_Uniq.txt

The sort function puts them in alphanumeric order. Once the two files are sorted, they are compared, and I only take the output of the RR log file that is unique. Now I have eliminated all errors that were in both files. Thus, any errors that were in LineageOS were okay for booting (not okay totally, but didn’t prevent function).

Now I have a list of just the unique lines. Now I can just grab the errors:

cat Just_rr_Uniq.txt |grep ^” E”

And viola! Now I am only looking at the errors that are unique to the RR rom. That cut my file from 28000 lines to a simple 1280! Whatever these errors are, they would be a good place to start looking, since they only happen on the rom that doesn’t work properly.

It’s also good to keep your original logcat untouched, so you can reference it later. Note that the grep’d, sorted, and cut file will be missing key information around the error you are looking at. Hopefully that helps you get pointed in the right direction.

Linux – keep it simple.

Resurrection Remix Pie for the XA2 Ultra!

To God be the glory, I finally finished a XA2 Ultra build of Resurrection Remix! It’s Resurrection Remix, Pie flavored! You can check it out on XDA if you would like, but here is my post from there:

Here’s a quote from RR:

We work to make your android experience elegant. Handpicked features beautifully packed into one ROM.

**** This is an UNOFFICIAL ROM. Install at your own risk! ****

A huge thanks to the Resurrection Remix team! Another huge thanks goes out to XDA developer LuK1337 for all of the great development that he did on the Sony Xperia XA2 Ultra! He did most of the heavy lifting by making a great LineageOS build, upon which this RR is based. Please note, this is an UNOFFICIAL ROM.

Disclaimer: Resurrection Remix is not responsible for any damages to your device.
All of my work is completely available for any who wish to use or modify it. I didn’t make Resurrection Remix, the device trees, or vendor blobs. I simply used and edited existing material. A huge thanks should go to those who actually created this stuff.

This Unofficial Resurrection Remix Pie ROM was built for H3223 (discovery), but may work on some of the other variants, please try at your own risk. However, if you do try it on another variant, please be sure to let me know in the comments how it worked.

Rom Download link:
WARNING: This is only for those on firmware versions 50.1.xxxxxx, not for those who are on firmware versions 50.2.xxxx and up. I plan on working on updated firmware versions later.
There is an ENGINEERING and USERDEBUG build. The ENG build is marked “ENG” for testing purposes only. You can install anything you want, but I recommend not installing the ENG build.

Gapps link:
If desired. Personally, I’ve gone Gapp-less.

Installation instructions:
-Download ROM and gapps, and put them on your removable sdcard storage. (Or leave on your computer and flash with adb sideload.)
-Reboot into the bootloader.
-Fastboot boot your TWRP.
-Backup what you had. (Just to be safe.)
-Wipe everything and format data.
-Install Rom. (Either from adb sideload or from your removable sdcard storage.)
-Reboot to system and enjoy!
If you also want Gapps:
-Reboot again into the bootloader.
-Fastboot boot your TWRP.
-Install Gapps. – Optional
If you plan to install magisk (good idea), then let the rom boot the first time, then go back to TWRP and flash magisk. This is optional, of course.

What works:

So far everything that I have tried works, such as

Camera for pictures and video, Phone calls, Data 3g/LTE, Bluetooth, WiFi, MTP, etc….

What doesn’t: Nothing that I know of, but if you find something, please let me know so we can try to fix it!

Source Code:
Official website:
My device trees, vendor blobs, and kernel source:

ROM OS Version: 9.0 Pie
RR version: 7.0.2
ROM Kernel: Linux 4.4.153
Based On: The best of every ROM, but particularly based on LineageOS.

Created 2019-08-16

Linux – keep it simple


Android meets Arduino!

As you guys know, I don’t really do “product reviews”. But if I find a handy tool, and use it, then it is fun to share that info with others. One such tool is Bluino Loader, an Android app that lets you create Arduino files, upload them to your boards, and even monitor the serial connection over USB. It’s pretty handy!

As with any “code from your phone app”, it is a bit tedious to type a lot of code with the Android keyboard. So I don’t use this app a lot when it comes time to create code. One of the big things that I like to do with it, though, is to monitor the serial output over a USB OTG cable.

Using the OTG cable, I can hook the Arduino Uno board directly to the phone, which also powers the board. Then I can open up Bluino Loader and click the icon at the top to monitor the serial connection. It can’t get much simpler than that. Within seconds I have serial data coming in and being displayed in the terminal. I even used it to test out the 433 MHz transmit and receive functions from my last test project. Worked like a charm!

Linux – keep it simple.

Android Remote Control through ADB

Today, I stumbled on perhaps the most ingenious use of ADB ever:

Remote control your Android phone through adb

A program and write-up by Marian Schedenig, that they shared on their website. This is perhaps the best adb tool I have ever seen, in that it takes three simple principles and puts them together to allow you to remote control your phone over ADB with your mouse, without ROOT permission!


Here is a small gif that I put together from a screen recording of me using this awesome java tool. Essentially, it uses adb to take screen shots of the phone. Then it downloads the screen shot and updates it’s display. Finally, when you click on the screen, it sends an x/y co-ordinate to the phone over adb to tell it you swiped or clicked! It is absolutely brilliant!

The updates are a little slow, and you do have to edit the config file for your specific needs, but it works great, and is a really useful tool if you broke your screen or have touch screen issues, or just need to display your screen for an audience to view while you press buttons or work with apps. Since it is written in java, it is cross platform as well!

Linux – keep it simple.

YouTube milestone, 1000 subscribers want to know how to build Android!

Hey everyone! Praise God! Great news! I just passed 1000 subscribers on YouTube and I just wanted to take a minute to thank all of you for taking this journey with me.

It’s a bit funny, since I thought that posting the original videos about building Android was a one time deal, and after that I would be done making them. Through your encouragement and questions, I’ve now got over 240 videos all about building android and apps.

I have a new link for my channel:

But don’t worry, the old one still works if you have it bookmarked.

I’ve got a few more adventures in android building coming up, including upgrading the BLU phone to Oreo ( I was able to boot Oreo the other day, it doesn’t work very well, but it is pretty good progress for a lollipop phone ), including marshmallow and nougat along the way.

Please keep the questions and suggestions coming in, as these help me understand what videos I should focus on next. Down the road I hope to make some videos on building without ninja and jack, as well as building generic system images ( gsi ). Thanks again everyone!