error: vendor/qcom/opensource/cryptfs_hw/Android.bp:27:37: unrecognized property “product_variables.lineage.uses_metadata_as_fde_key”

Another random error while compiling AOKP pie for the XA2 Ultra. These calls work properly when compiling Lineage, but don’t work in the AOKP source tree, so I did some digging.

error: vendor/qcom/opensource/cryptfs_hw/Android.bp:27:37: unrecognized property “product_variables.lineage.uses_metadata_as_fde_key”

In the end, I found that the only way around it was to remove the unrecognized property, since this isn’t LineageOS, it isn’t declared anywhere in AOKP. So, I edited vendor/qcom/opensource/cryptfs_hw/Android.bp at line 27, like so:

//WJH uses_metadata_as_fde_key: {
//WJH cflags: [“-DUSE_METADATA_FOR_KEY”],
//WJH },

By commenting them out, they are basically deleted. This seemed to work well, and so far, hasn’t hampered any of the rom functions.

Linux – keep it simple.

Advertisements

system.com/vold/Ext4Crypt.cpp:204:12: error: use of undeclared identifier ‘fs_mgr_is_wrapped_key_supported’

Another strange set of errors while compiling AOKP. It seems like they are in the middle of merging some Lineage commits, but didn’t finish them. Either way, I ran into this problem with Ext3Crypt:

compile system.com/vold/Ext4Crypt.cpp:204:12: error: use of undeclared identifier ‘fs_mgr_is_wrapped_key_supported’

So, I took a look at line 204 from system.com/vold/Ext4Crypt.cpp, and this is what I saw:

bool is_wrapped_key_supported() {
return fs_mgr_is_wrapped_key_supported(
fs_mgr_get_entry_for_mount_point(fstab_default, DATA_MNT_POINT));
}

This didn’t make sense to me, since the call is for a bool, the answer must be true or false, zero or one. Instead it is trying to grab some information and determine if it is true or false based on that. I spent hours trying to crack down on it, but I couldn’t find how this all washed out. In the end, I made this edit to get through this error:

bool is_wrapped_key_supported() {
//return fs_mgr_is_wrapped_key_supported(
// fs_mgr_get_entry_for_mount_point(fstab_default, DATA_MNT_POINT)); //WJH
return false; //WJH
}

Essentially, I returned false. I debated about what to return, but I don’t want it to use it, since I can’t correctly fix it, so I decided false was my best bet. Sure enough, that worked.

Linux – keep it simple.

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’
mpClientInterface->onDynamicPolicyMixStateUpdate(policyMix->mDeviceAddress,
~~~~~~~~~ ^
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.

audio

Linux – keep it simple.

Mounting a Virtual Box “vmdk” image shouldn’t be this hard….

vmdk

And it wasn’t, well, once I learned how to do it properly. Unfortunately it took me an hour to get there! First I monkeyed around with vmware-tools, and vmware-mount, and then I tried kpartx, and all of it was a wash.

Then, after more searching online, I found a guy that made it plain and simple:

sudo modprobe nbd
sudo qemu-nbd -r -c /dev/nbd1 ./NewVirtualDisk1.vmdk

And that was it! Ubuntu automatically mounted it for me and it popped up on my desktop! It’s amazing when you spend hours following other tutorials, installing more and more things, only to find that there was a simple tool or way to do this that was there all along.

Hopefully it saves you the same headache!

Linux – keep it simple.

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

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: {com.android.systemui: android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, com.android.systemui: android.permission.PACKAGE_USAGE_STATS, com.android.settings: android.permission.ACCESS_FONT_MANAGER, com.android.settings: android.permission.NAVIGATION_EDITOR, com.android.systemui: android.permission.FORCE_STOP_PACKAGES, com.android.launcher3: 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:

/frameworks/base/data/etc/privapp-permissions-platform.xml

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

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

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=”com.android.launcher3″>
<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”/>
</privapp-permissions>

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:

/vendor/rr/config/permissions/privapp-permissions-lineage.xml

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: {com.android.systemui: android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, com.android.systemui: android.permission.PACKAGE_USAGE_STATS, com.android.settings: android.permission.ACCESS_FONT_MANAGER, com.android.settings: android.permission.NAVIGATION_EDITOR, com.android.systemui: android.permission.FORCE_STOP_PACKAGES, com.android.launcher3: android.permission.STATUS_BAR}
08-14 15:55:22.358 1468 1468 E System : at com.android.server.pm.permission.PermissionManagerService.systemReady(PermissionManagerService.java:2005)
08-14 15:55:22.358 1468 1468 E System : at com.android.server.pm.permission.PermissionManagerService.access$100(PermissionManagerService.java:89)
08-14 15:55:22.358 1468 1468 E System : at com.android.server.pm.permission.PermissionManagerService$PermissionManagerInternalImpl.systemReady(PermissionManagerService.java:2052)
08-14 15:55:22.358 1468 1468 E System : at com.android.server.pm.PackageManagerService.systemReady(PackageManagerService.java:21423)
08-14 15:55:22.358 1468 1468 E System : at com.android.server.SystemServer.startOtherServices(SystemServer.java:1791)
08-14 15:55:22.358 1468 1468 E System : at com.android.server.SystemServer.run(SystemServer.java:464)
08-14 15:55:22.358 1468 1468 E System : at com.android.server.SystemServer.main(SystemServer.java:309)
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 com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
08-14 15:55:22.358 1468 1468 E System : at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
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: {com.android.systemui: android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, com.android.systemui: android.permission.PACKAGE_USAGE_STATS, com.android.settings: android.permission.ACCESS_FONT_MANAGER, com.android.settings: android.permission.NAVIGATION_EDITOR, com.android.systemui: android.permission.FORCE_STOP_PACKAGES, com.android.launcher3: android.permission.STATUS_BAR}
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.pm.permission.PermissionManagerService.systemReady(PermissionManagerService.java:2005)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.pm.permission.PermissionManagerService.access$100(PermissionManagerService.java:89)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.pm.permission.PermissionManagerService$PermissionManagerInternalImpl.systemReady(PermissionManagerService.java:2052)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.pm.PackageManagerService.systemReady(PackageManagerService.java:21423)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.SystemServer.startOtherServices(SystemServer.java:1791)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.SystemServer.run(SystemServer.java:464)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.server.SystemServer.main(SystemServer.java:309)
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 com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
08-14 15:55:22.359 1468 1468 E Zygote : at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
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: {com.android.systemui: android.permission.NAVIGATION_EDITOR, org.omnirom.omnistyle: android.permission.CHANGE_OVERLAY_PACKAGES, com.android.systemui: android.permission.PACKAGE_USAGE_STATS, com.android.settings: android.permission.ACCESS_FONT_MANAGER, com.android.settings: android.permission.NAVIGATION_EDITOR, com.android.systemui: android.permission.FORCE_STOP_PACKAGES, com.android.launcher3: android.permission.STATUS_BAR}
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.pm.permission.PermissionManagerService.systemReady(PermissionManagerService.java:2005)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.pm.permission.PermissionManagerService.access$100(PermissionManagerService.java:89)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.pm.permission.PermissionManagerService$PermissionManagerInternalImpl.systemReady(PermissionManagerService.java:2052)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.pm.PackageManagerService.systemReady(PackageManagerService.java:21423)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.SystemServer.startOtherServices(SystemServer.java:1791)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.SystemServer.run(SystemServer.java:464)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.server.SystemServer.main(SystemServer.java:309)
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 com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
08-14 15:55:22.361 1468 1468 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
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).

lin_rr

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.

Downloads:
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.
http://www.mediafire.com/folder/6ni8bw8ansajf/pie
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:
[url]http://opengapps.org/[/url]
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:
https://github.com/ResurrectionRemix
Official website:
http://www.resurrectionremix.com/
My device trees, vendor blobs, and kernel source:
https://gitlab.com/alaskalinuxuser

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.

Still using AsteroidOS and loving it!

image

A while back I switched my LG Watch Urbane (bass) from Android Wear to AsteroidOS. My initial reaction was really positive, but I wanted to come back to post later on how the long term use was going. Truth is, it’s great!

image

Don’t get me wrong, Android Wear had some nice features, a few of which I still miss. Most notably the one where the motion of turning your watch towards your face caused the screen to turn on.

image

But other than that, AsteroidOS has met every need I have in a smart watch. Most notably that of telling time and the synchronized phone notification. Of course the weather and calendar apps are handy too. When it really comes down to it, I realized that I didn’t use Androids thousands of apps on my watch because the screen is too small. Why would anyone watch an HD movie on a 1.5″ screen?

AsteroidOS has really been great at having useful apps that one would actually want to use on the small screen, which just makes sense. I’ve also gone weeks or more without rebooting the watch. The firmware is really robust and never seems to have an issue.

The best part of all? The battery life is phenomenal! Since switching, I went from about 9 or 10 hours with Android Wear to 2 days with AsteroidOS. And that’s a win win for me!

Linux – keep it simple.

Fixing a Galaxy Note 9 with broken glass

image
Well, at least attempting to. Unfortunately it didn’t end very well. A friend of mine broke the glass screen of their Samsung Galaxy Note 9. They have a warranty on it, but they already broke the screen once, and now they would have to pay several hundred dollars to have this one fixed again.

Remember: Glass screen protectors are your friend! A case doesn’t protect the screen! Always buy a glass screen protector!

They bought a replacement glass kit for around $30 and hoped to do the work themselves and save a lot of money. Once they started watching how to videos, though, they realized that they were in over their heads. So, they came to me…..

Of course, my first suggestion was that they seek a professional. Turns out the only professional in our town wanted $300 to do the work. Unfortunately for my friend, that was still too much. So, they asked me to give it a try first.

I told them this wouldn’t work. I don’t have the right equipment. I don’t have a warranty. I could ruin the screen. But, they were persistent, so I gave it a go.

The key is to get the glass hot, but not hot enough to melt the screen. So I used a heat gun and a thermometer to adjust it to 90 degrees Celsius. Once that was set I started heating the glass.

Then, using a toothbrush, I started applying isopropyl alcohol to the shattered portion of the screen. This breaks down the glue. As carefully as I could I used plastic screwdriver type tools to lift off the broken chunks of glass.

All was going really well for the first 30 minutes. I had lifted off the glass in about the shape and size of a quarter, and was moving right along. And then… while lifting a longer piece of glass, it levered against the screen, and poked the digitizer, causing a huge green line and purple line right down the middle of the display!
image
I was really bummed! Now the screen and the glass were ruined, and, despite the warnings I gave my friend beforehand, I’m pretty sure that they lost all confidence in my phone skills. They ended up turning it in for repair.

So, the moral of the story is: buy a good glass screen protector, and don’t try to fix broken glass without the right tools.

Linux – keep it simple.