AudioPolicyManager.cpp:2240:65: error: member reference type ‘android::AudioMix *’ is a pointer

Well, that was a new one to me! I had just build LineageOS and Resurrection Remix for the XA2 Ultra, and now I got this error in the first minute of trying to build AOKP. Here’s the full error:

vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2240:65: error: member reference type ‘android::AudioMix *’ is a pointer; did you mean to use ‘->’?
sp<AudioPolicyMix> policyMix = inputDesc->mPolicyMix.promote();
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2240:66: error: no member named ‘promote’ in ‘android::AudioMix’
sp<AudioPolicyMix> policyMix = inputDesc->mPolicyMix.promote();
~~~~~~~~~~~~~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2243:37: error: no member named ‘mCbFlags’ in ‘android::AudioPolicyMix’
&& ((policyMix->mCbFlags & AudioMix::kCbFlagNotifyActivity) != 0)) {
~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2244:77: error: no member named ‘mDeviceAddress’ in ‘android::AudioPolicyMix’
~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2265:39: error: no member named ‘mMixType’ in ‘android::AudioPolicyMix’
} else if (policyMix->mMixType == MIX_TYPE_PLAYERS) {
~~~~~~~~~ ^
vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp:2266:42: error: no member named ‘mDeviceAddress’ in ‘android::AudioPolicyMix’
address = policyMix->mDeviceAddress;
~~~~~~~~~ ^
6 errors generated.

Ironically, the vendor/qcom/opensource/audio/policy_hal/AudioPolicyManager.cpp file is common to all three ROMs, Lineage, RR, and AOKP. So how is it that it fails on AOKP, but gives me no errors on Lineage or RR? As it turns out, there was a commit to /frameworks/av in Lineage and RR that was not performed on AOKP. You can take a look at the commit yourself if you’d like.

Essentially, you have a situation where the target ROM (AOKP) has dependencies mixed from the source ROM (LineageOS). Some of these dependencies were updated with the new code, and some were not, making a half done product that didn’t build. This is one of the problems when you are working on the latest versions of custom ROMs, is that there may be a few errors that are due to dependencies being changed.

So, there were two options for fixing this:

  1. Update /frameworks/av to match LineageOS.
  2. Rollback the changes in qcom’s audio policy.

The first is the most progressive, as the changes will probably come to that anyways, but it may require making other changes to more and more files. Just perusing the files looked like changing 10 files on about 80 different lines, but these may affect other files or lines as well.

That said, the simpler answer was to go with the second option and roll back the changes in the qcom audio policy. This only required changing about 6 or 7 lines in one file, which was much easier to accomplish.

If you look at the commit that made the changes, you can see the few lines that are edited to make this work properly. Fortunately the quick rollback fixed the issue and allows the build to continue.


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


Engineering Pie Build for the Sony Xperia XA2 Ultra!

So it’s been a rough start for me, stepping into the modern world with a modern phone that has a/b partitioning and was Android 8.0+. I’ve built dozens of roms for dozens of phones, some that were even unsupported, and to God be the glory, I was moderately successful, but these modern phones have been a different story. My first attempt with the Xperia XA2 Ultra ended up hard bricked. Then, I built a pie version of AOKP, which did boot, but would immediately crash after getting to the home screen.

Today, however, was off to a much better start. I successfully tested my engineering build of LineageOS 16.0 (pie) for my XA2 Ultra (discovery). Everything seems to work well, and you are welcome to try it out. Keep in mind, though, it is an engineering build as opposed to a user build. Also note that this is for the 50.1.x firmware variants.

Granted, a lineage build is already available, and most of the work was done by Luke. I like to compile a build on my own, though, to make sure my system is set up properly and that the source material does work before I get started on my own roms.

Now to get back to that AOKP build…. Or should I start on a Resurrection Remix build instead?

Linux – keep it simple.

Beginning AOKP Pie for the Xperia XA2 Ultra

I knew I couldn’t keep away from Android forever. It was only a matter of time before I jumped back into development. A lot has changed since my old rom building days. Back then everything was pre-treble, and there were no A/B partitions. That all changed for me with an Xperia XA2 Ultra.

It seems harder than I remember, and a lot more time intensive than it used to be. But, to kick things off, I started by building AOKP Pie for my new phone. To God be the glory, it does boot, but it doesn’t work right. Something is causing a pretty big hang up as soon as you are done with the setup. It locks up graphically once you get to the home screen for the first time.

Initial thoughts are perhaps tiles or menu item problems, but we will see.

Under the hood, though, everything is still running, even though the screen doesn’t update. If you use ADB, you can connect and do all the usual ADB command line stuff. But that doesn’t make for a very handy cell phone if you have to bring your computer everywhere so you can use it!

It’s also a bit harder as I had to switch to a nano sim card to be able to use the XA2. This is a problem because all of my other phones are not nano. It makes it difficult to switch to another phone while I test this out. Using a phone as your daily driver and for developing is a bit cumbersome and does slow me down quite a bit, but hopefully I’ll be able to work on it more later.

If you want to try out the “alpha” of my rom, you can download it on my MediaFire account. I will warn you, though, it doesn’t work very well.

Linux – keep it simple.

Video Tutorial on How to Compile Android and Modify Kernels


For those interested, I have just posted a video tutorial series on XDA for building Android Oreo, Nougat, Marshmallow, and Lollipop on 5 different phones, the emulator, and 5 different ROMs. Also included are custom kernel editing, adding apps, changing source code, backgrounds, and more. Here’s what I posted:

From XDA:


Praise God! Finally a video tutorial of how to build Android and modify kernels!

I have created a video tutorial and guide for how to compile Android, from Lollipop through Marshmallow, Nougat, and Oreo. The video series covers several different phones, the emulator, kernel and rom editing, app source code editing, and much more!

Who is this video series for?
Well, this video tutorial is a step by step guide built primarily for the beginner. This is written for those who already know how to flash TWRP, CWM, or the like, and who have installed a custom rom before. This is designed to help those who are ready to move up from flashing and installing other peoples custom rom to actually start making their own custom roms. I recommend that a beginner watch the entire series in numerical/alphabetical order (the videos are marked).

That said, I believe that an intermediate developer may find a useful trick here and there, and they should just skip ahead to videos of interest. Perhaps kernel development, or something along those lines.

An advanced rom/kernel developer will probably far exceed my feeble abilities, and will not likely find much useful information here. Perhaps if you are an advanced developer, you would consider continuing the tutorial or making an advanced video series! (See further posts for recommendations on contributing videos.)

Why did you put this together?
Well, after building roms for several different devices, I started receiving requests from users who wanted to start building their own roms, but didn’t know how. I didn’t have enough time to answer everyones questions, so I wrote a few guides, pointed others to guides that were available, but there are some things that you just need to see to understand. Hence, the video tutorial. I just hope that someone finds it useful.

This course was written in order! While Lollipop and Marshmallow are old by today’s standards, there is still good learning value in building them, and there are topics covered there that really make them worth watching.

What’s in the videos?
During the series, we will be building for the emulator, as well as 5 different phones of various brands, and 5 different roms. I hope that this will give the viewer a good idea of how to build for their own specific phone as they see the differences and similarities across the phones and custom roms.

+ Ubuntu installation
+ Java installations
+ Using Git, GitHub, GitKraken, and the command line
+ Fastboot and ADB
+ Heimdall/Odin
+ QFIL, QPST, SALT, and other tools
+ AOSP, SlimRoms, PACrom, AOKP, AOSCP
+ Lollipop, Marshmallow, Nougat, Oreo
+ Errors
+ Overclocking CPU/GPU
+ Adding Governors and I/O Schedulers
+ Sound modifications
+ Changing app colors, text, and icons
+ Adding prebuilt apps
+ Adding source code
+ Converting device from one rom to another

**** This is an UNOFFICIAL TUTORIAL. Use at your own risk! ****
Download links:
Ogg Vorbis Video GitLab:
Clicking on a video in GitLab will allow you to watch it online.

Ogg Vorbis Video Downloads:
This download is rather large due to the multiple videos.

MP4 Video GitLab:
Clicking on a video in GitLab will allow you to watch it online.

MP4 Video Downloads:
This download is rather large due to the multiple videos.

I also have several written guides available on XDA, here are a few:

Building ROMs for the Galaxy Note Edge: [url][/url]
Building ROMs for the Galaxy S4: [url][/url]


Be sure to check out the videos or the XDA thread! I hope that these will help some of the aspiring Android developers out there!

Linux – keep it simple.

New builds! New device! The N915T Galaxy Note Edge!

While I don’t have one yet, I have decided that I will be getting one of these Galaxy Note Edge phones. They are a couple years old, and the price on them is going down significantly. In the meantime, I noticed that there were not very many custom roms available for them. Actually, there are only 2 roms that are not just modifications of stock roms. Those two roms are CM 12.1 (Lollipop) and Resurrection Remix (Marshmallow).

So, I decided to build some of my own. To God be the glory, it worked! Well, sort of.

Working with a group of willing testers, I have put together this rom:

At this time, it does not have functioning WiFi or Cellular, but it is a start. It is my hope to continue working on this and get it squared away. For now, it is a fun Alpha teaser to try out.

Some of the main problems with custom roms on this phone is the “edge” feature. The curved glass edge has never truly been done justice by a non-touchwiz rom, which I suspect is why most stick with the stock roms, or modifications thereof.

My long term goals are to find a way to put the edge back into play, and to also make the s-pen fully functional. Short term goals are to get the usual hardware working. If you have a N915T, feel free to try out this alpha build, but remember, it is not a daily driver yet.

Linux – keep it simple.

Testers requested for AOKP 6.0.1 on the Note Edge, T-Mobile variant.

Testers requested for AOKP 6.0.1 on the Note Edge, T-Mobile variant.

Hi, I have built several roms for other phones, both personally, and shared here on my website, or on XDA.

The Note Edge N915T is getting pretty cheap to buy off of Swappa, Ebay, and Amazon, and I was thinking about picking one up. I am a dad, so I have to be frugal and stick with older/cheaper phones. I can’t afford to buy everybody in the family a new cell phone! As I save up a few bucks for it, I was thumbing through the forums and noticed that there were not many non-stock based roms available for it. So, I built one. By God’s grace it compiled after a few tries of error fixing. I would like to ask for any volunteers to assist me with testing it out.

The applicants would need a little bit of knowledge:

– Have a N915T variant
– Have TWRP installed
– Know how to make a backup
– Know how to wipe and flash roms
– Preferably be able to use adb (I can help with that)
– Know how to recover back to stock rom or TWRP in the event of a failure
– Know how to take screenshots/pictures (common sense is in fact a super power)

Essentially, if interested, click on the “contact” link in the bar at the top. Fill out the contact form with a valid email address, and I will email you a reply with a link to Media-Fire for the download and I would include instructions.

If it fails, well, you can just jump back into TWRP and restore your daily driver.

If it passes, I can  list you as an Alpha/Beta tester!

I never charge money for my rom work, I do not accept donations, so this is not a ploy to exploit cash from anyone. I just like building custom roms, and I am really interested in building one for this phone.


You can click on the “Homemade Roms” link above if you would like to check out some of my other work.

Linux – keep it simple.

How to manually update your custom rom source code with security updates

For those of you who compile your own custom roms directly using AOSP source, the latest security updates are always added in as soon as they occure. For those of us using custom roms, such as SlimRoms, AOKP, PAC roms, and others, this is not always the case.

Because the custom rom community downloads AOSP source, and then manipulates it to their needs/tastes, they cannot always directly integrate AOSP security updates. Some of these updates may not apply. Others, if unedited, may cause some features not to function.

For this reason, custom roms can sometimes fall behind, because one of the developers on that team needs to manually apply a lot of the fixes. This can be quite tedious. For instance, the libvpx security issue found in March of 2016 changed over 800 files. For the most part, the custom rom teams do a great job updating the security patches for the current version of their rom. The question is, what do you do to update the security patches of older versions of the roms?

This is actually a problem that I ran into with my build of SlimLP for the SGH-M919, T-Mobile Galaxy S4. I am mainting a current build of SlimLP for that phone, because the Marshmallow builds have some Bluetooth issues on these phones. Thus, users who still want to use Lollipop roms still need up to date security. But how do I fix this problem? The SlimRom’s team has moved on to work on Slim6, and there is almost no activity on SlimLP. Well, by God’s grace, I figured it out, and I thought I would share that here with you, in case you face a similar problem.

First, you could apply these same methods to all levels of security, however, since there are so many security updates, I have decided to only manually update my SlimLP source code with Critical security updates. Yes, that does mean that I am skipping the High, Moderate, and Low security threats. As I mentioned before, some of the updates are over 800 files, and that would be a new full time job for me, which I don’t have time for. So, hopefully, these Critical updates will strike the balance between keeping my rom users safe, and allowing me to still have time for important things like family, work, and sleeping!

The first thing I noticed as I started building SlimLP in May was that the security updates had stopped in February. After syncing in August, I found that the security updates had still not changed. You can verify in your source (if it is Lollipop or later) by looking at /build/core/, where you should see this line:

# Used to indicate the security patch that has been applied to the device.
# Can be an arbitrary string, but must be a single word.
# If there is no $PLATFORM_SECURITY_PATCH set, keep it empty.

Obviously, if it is now August, then the security patches are 6 months out of date. That is pretty old, and there were a lot of big security threats found since then, some of which are specific to Qualcomm phones. This prompted me to start the process of updating my source by hand.

Granted, you could also join the team of your favorite rom and help others by updating thier security patches too, but as I pointed out, I am only updating the Critical security updates, not all of them, so it would not meet all of the official requirements to push my source upstream. If that is something you are interested in doing, that is great!

The next thing I did was look at the current security updates by going here:

I decided to work on one month at a time, and compile inbetween to make sure that each update did not break anything that is in my SlimLP rom. So, I clicked on March, 2016. There were 19 CVE’s, or Common Vulnerability and Exposures ID’s for that month, 7 of which were marked Critical. Those are the ones I decided to work on.

There are many different ways to go about this, but here is what worked best for me. I copied the CVE number, in this case, CVE-2016-0818, and punched it into Google. Google brought up several options, but I found a good one to click on is the NVD detail, which is teh National Vulnerability Database. In this case, it took me here:

The website has a poor color scheme, but is very informative. It tells you what type of threat this is, how it can be used, and other great information. There is also a section called “References to Advisories, Solutions, and Tools”, below which I found several hyperlinks, including this one, which contains the fixes:

This Google Git page shows us where the file is located, and how many, and exactly which file(s) have been changed. For this particular CVE, it is a really small change of just one file:

src/platform/java/org/conscrypt/ [diff]

By clicking on the word [diff], you are brought to the next page, that shows you exactly which lines of code need to change, like so:

@@ -68,6 +68,15 @@
if (anchors == null) {
anchors = new ArrayList<TrustAnchor>(1);
subjectToTrustAnchors.put(subject, anchors);
+ } else {
+ // Avoid indexing the same certificate multiple times
+ if (cert != null) {
+ for (TrustAnchor entry : anchors) {
+ if (cert.equals(entry.getTrustedCert())) {
+ return;
+ }
+ }
+ }

If you have never read these before, the + signs tell you to add these lines. Any – signs tell you to delete those lines. At the top, the @@ -68,6 +68,15 @@ is used to tell you which line numbers to look for, such as the case here, of line 68. Pretty straightforward. So, in this case, I found that file, and made these changes of adding these new lines. Note, in some of the files I changed, the line numbers were not correct for where to find this portion of code. The easy thing to do is copy a snipit of the code and do a search in the file, corrolating that with the surounding code and approximate line numbers for guidance. This is especially true if that file has been hacked to add some function or feature to your rom.

The next step is to go back to where we started. If you recall, we looked in /build/core/, where we saw this line:


Now we can update it if we desire. Granted, if you are not doing all of the updates, you may not wish to change this, as you do not want to intentionally mislead anyone. In my case, I did update it, but was very sure to write in my rom’s long description that the security updates are only the Critical updates that I applied by hand, as of 2016-02-01. How you handle this is up to you.

Obviously, the last step is to go ahead and compile your new code, and see if it still works right! Hopefully, you now have a more secure rom for your phones.

Linux – keep it simple.

Adding pre-built apps to your build

One of the big things that always comes up is that of adding pre-built apps to your build. Make is so dynamic that you could add these in just about anywhere, provided that you properly add them to your configuration files. For myself, I used to add them into the vendor directory, but this became tedious when I would switch to build something else with the same repository, or when I would update or change to other repositories but wanted the same pre-built apps.

I recently realized that there was an easy way around this, and I wanted to share that with others. Most of you probably already know how to do this, but perhaps someone can benifit from this. Besides, if I ever forget, I can just look here for a reference!

I like to add the Kernel Adiutor app to my JFLTETMO (Samsung Galaxy S4, T-Mobile variant) builds. Like I mentioned above, I used to put it in the vendor directory. What I realized though, is that I can simply add it to my jfltetmo repository under the devices. For my device, I have a jfltetmo repository, which essentially sets a few flags and passes the buck to the jf-common repository for building. So, I actually added the app to my jf-common repository. Now, when I sync, it updates my jf-common directory, and keeps my prebuilt app!

Here is what I did.

Added some folders:

In my jf-common repository (dev/samsung/jf-common) I added a directory called “prebuilt”. In keeping with Android’s common structures, I then created these two folders: “common” and in that folder, one called “app”.
When you are done making directories, it should have a path like this:


Now, in the “app” folder, I placed my prebuilt app, the Kernel Adiutor app, which I named “ka.apk”. I then made an file in the “prebuilt” folder that looks like this:

# Copyright (C) 2012 The Android Open Source Project
# Licensed under the Apache License, Version 2.0 (the “License”);
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an “AS IS” BASIS,
# See the License for the specific language governing permissions and
# limitations under the License.

LOCAL_PATH := $(call my-dir)

# Prebuilt APKs

include $(CLEAR_VARS)
LOCAL_SRC_FILES := common/app/$(LOCAL_MODULE).apk

You can add as many prebuilt apps as you want this way, just make the above block for each app. Then you simply add them to your file in the jf-common directory. You can substitute your device name here, it should work the same. Notice that the lines which have more than one app have the “\” denoting that there are more files to add. Pretty simple, right?

# WJH adding kernel adiutor apk
ka \

Linux – keep it simple.


Using a fallback branch to overcome poor choice of repository branch names

I know that we have looked at fallback branches before, but this really is worth looking at again. Last time, we saw an instance where there was not a branch available that was new enough for what we were trying to build. E.g., building a Lollipop version of Android, with only KitKat trees available. This time, however, we have a case of “mistaken” identity. Check it out:

Calculated revision: lp5.1-layers
Default revision: android-5.1.1_r24
Default revision android-5.1.1_r24 not found in android_device_samsung_jfltetmo. Bailing.
Branches found:
Use the ROOMSERVICE_BRANCHES environment variable to specify a list of fallback branches.
build/core/ *** Can not locate config makefile for product “liquid_jfltetmo”. Stop.

** Don’t have a product spec for: ‘liquid_jfltetmo’
** Do you have the right repo manifest?

Here we are trying to build a Lollipop version of Android, and it is looking for a branch called lp5.1-layers, but will use the default of android-5.1.1_r24 if it is available. It couldn’t find it, however, because in the source I am refering too, the branch is called lollipop instead. Now, you and I know that Lollipop and 5.1.1 are the same thing, but the compiler and repo tools do not. So, here’s how we fix it, by using a fallback branch option, except instead of “falling back” to an old revision, we are “falling back” to the current revision under a different name:

alaskalinuxuser@AlaskaLinuxUser-HP-Compaq-6715b:~/Documents/projects/phones/compile/Liquid5$ export ROOMSERVICE_BRANCHES=lollipop
alaskalinuxuser@AlaskaLinuxUser-HP-Compaq-6715b:~/Documents/projects/phones/compile/Liquid5$ brunch jfltetmo
————Edited for space————-
Device jfltetmo not found. Attempting to retrieve device repository from LiquidSmooth-Devices Github (
Found repository: android_device_samsung_jfltetmo
Checking branch info
Calculated revision: lp5.1-layers
Default revision: android-5.1.1_r24
Using fallback branch: lollipop
Adding dependency: LiquidSmooth-Devices/android_device_samsung_jfltetmo -> device/samsung/jfltetmo
Syncing repository to retrieve project.
Fetching project LiquidSmooth-Devices/android_device_samsung_jfltetmo
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 –:–:– –:–:– –:–:– 0

Now it “found” it! Using the fallback branch is a great way to overcome all of the different naming conventions out there.

Linux – keep it simple.