With a custom AOSP build on the Nexus 5X (bullhead), the SIM Card fails to work.

3,340 views
Skip to first unread message

Douglas Selph

unread,
Jan 15, 2016, 11:41:45 AM1/15/16
to Android Building
  1. I built android-6.0.1_r8 for bullhead.
  2. I flashed this onto the device using: fastboot -w flashall -p bullhead from the AOSP top.
  3. When the system comes up, a message displays "There is an internal problem with your device."
  4. The SIM card fails to work. I have no cellular ability.
  5. I don't have vendor or proprietary sources (i.e. no vendor directory) because I see in other posts that these are in theory unneeded.
    Somehow vendor.img is already on the device. What doesn't make sense to me with this idea, is that I have always needed specific proprietary images for each version that I am building. That is, if I have a 6.0.1_r8 build, then I needed specific proprietaries for that version. If I am building on a different version, then another set are needed. This made sense to me, since the API's could have changed and therefore everything needs to sync up. With the current model, it assumes that there are no API changes. That hasn't been my interpretation of what I saw in the past.
How can I get my SIM CARD working?
Thanks,
Doug



Benton

unread,
Jan 18, 2016, 12:38:37 PM1/18/16
to Android Building
So I will start by saying I don't have a full solution to your issues but I know some of these as I am in the same boat.  I think the "There is an internal problem..." has to do with a mismatch in the vendor image version and the build version, which effects your build.prop file.  When they don't match, it throws that alert.  Your phone should already has a vendor image from the build that the phone was delivered with.  If I understand correctly, you are supposed to get the vendor.img from the corresponding factory images (https://developers.google.com/android/nexus/images?hl=en) that matches the build you created, which for your is 6.0.1_r8 or MMB29P.  At least that was how I thought it was supposed to work, but the BT on my build doesn't work at all.  Do you by any chance have working BT?

Thanks, hope it helps somewhat :D

Hamilton Turner

unread,
Feb 2, 2016, 2:09:32 AM2/2/16
to Android Building


On Friday, January 15, 2016 at 11:41:45 AM UTC-5, Douglas Selph wrote:
  1. I built android-6.0.1_r8 for bullhead.
  2. I flashed this onto the device using: fastboot -w flashall -p bullhead from the AOSP top.
  3. When the system comes up, a message displays "There is an internal problem with your device."
Prior emailer was mostly correct - this is caused by the build fingerprint stored in vendor.img not matching the one stored in system.img. See ActivityManagerService for the code that pops up this dialog (search for SHOW_FINGERPRINT_ERROR_MSG). This specifically relies on a call to Build.isFingerprintConsistent(), which itself just returns if the system properties ro.build.fingerprint == ro.vendor.build.fingerprint (the latter being set when vendor.img is compiled). Use "adb shell getprop" to check your own values. You cannot create a build fingerprint that matches the one inside the vendor bits unless you're working with the OEM, so aftermarket ROMs will always either show that dialog or choose to remove the code that displays it. 
 
  1. The SIM card fails to work. I have no cellular ability.
You're likely either missing a vendor component (this is the first time vendor.img has been used, and many people suspect some critical bits were "forgotten"), or a symlink such as the one that used to exist from /vendor --> /system/vendor . I've no idea which, sorry
  1. I don't have vendor or proprietary sources (i.e. no vendor directory) because I see in other posts that these are in theory unneeded.
    Somehow vendor.img is already on the device. What doesn't make sense to me with this idea, is that I have always needed specific proprietary images for each version that I am building. That is, if I have a 6.0.1_r8 build, then I needed specific proprietaries for that version. If I am building on a different version, then another set are needed. This made sense to me, since the API's could have changed and therefore everything needs to sync up. With the current model, it assumes that there are no API changes. That hasn't been my interpretation of what I saw in the past.
If I'm understanding properly, the new approach is to use `cat build/core/build_id.mk` to locate the build ID you are based off of. Then download the factory image for that precise build ID and flash it. I'd recommend to flash-all and boot the phone then walk through setup al the way to the home screen, because there are many partitions that are only configured by the proprietary blobs, so you want to ensure they are all 100% setup. Booting and going through setup seems to be more of a guarantee in my experience. Lastly, get back into fastboot, and then flash your modifications to system and other partitions, leaving vendor alone. Hope that nothing critical was left out of the vendor.img, or you'll be searching the web for proprietary blobs that have no build IDs attached, which is terrible.

By the way, I would be interested to know what you get w.r.t. dm-verity settings - e.g. do you see an orange warning at bootup, or a red, or some combination? 

 best, 
hamilton

Brian Yee

unread,
Feb 3, 2016, 10:10:00 AM2/3/16
to Android Building

Prior emailer was mostly correct - this is caused by the build fingerprint stored in vendor.img not matching the one stored in system.img. See ActivityManagerService for the code that pops up this dialog (search for SHOW_FINGERPRINT_ERROR_MSG). This specifically relies on a call to Build.isFingerprintConsistent(), which itself just returns if the system properties ro.build.fingerprint == ro.vendor.build.fingerprint (the latter being set when vendor.img is compiled). Use "adb shell getprop" to check your own values. You cannot create a build fingerprint that matches the one inside the vendor bits unless you're working with the OEM, so aftermarket ROMs will always either show that dialog or choose to remove the code that displays it. 

I'm trying to build the AOSP for the Pixel C and while I am getting this error I also get an error when I try to lock the boot loader again.  I feel like these errors are related.  The error I get when locking the boot loader is "OS on your tablet is damaged.  Needs Recovery".  I assume because it is doing an OS verification check that I am failing.

The in app error is easy to fix as you say you just remove the check, but how do I lock the boot loader again?  It seems like the unlocked boot loader causes a screen to display on every boot that says "your boot loader is unlock and the OS Verification check is disabled.  Will boot in 30 seconds"

I don't want to see this screen and to wait 30 seconds, so I lock the boot loader, but now I can't boot up.  Any ideas on what I would need to change and how to go about it?

If there is a way to edit the vendor.img to have the correct build.prop that would be awesome.  This needs to get done, so if i have to get down and dirty in kernel code or the boot loader so be it.  Instructions would be helpful though!

Thanks,
-Brian





Hamilton Turner

unread,
Feb 4, 2016, 7:42:15 PM2/4/16
to Android Building
Short answer: AFAIK, you cannot remove the warning at boot time unless you are working directly with an OEM or are an OEM. That comes from the bootloader, which is not an open component and you cannot readily modify. More details at https://source.android.com/security/verifiedboot/verified-boot.html and https://lwn.net/Articles/459420/ . The little dialog that shows when the framework first turns on is easily removable, but the actual warning on boot is not. 

I'm surprised to hear you can't boot if you re-lock the bootloader. In my experience this is not true - relocking just means you cannot flash more partitions without first unlocking again (which wipes the userdata partition). It doesn't remove the warning screen at bootup, which is what you're after, but it should not tank the bootup. According to the flowchart on dm-verity, all paths lead to "finish boot"

Best,
Hamilton

Brian Yee

unread,
Feb 5, 2016, 12:01:01 PM2/5/16
to Android Building
Thanks for the reply.

I mis-spoked a bit in my original post.  What I see happening is locking the bootloader after I put my new software on works fine.  The bootloader is locked but now I see a screen that says "OS on your tablet is damaged. Needs recovering."  It is a black screen an in the upper left I have options, using the had keys to navigate, to "Restart Device", "Switch to fast boot mode.","Reboot into Android Recovery.", "Turn Off Device" and "Switch to USB Recover"

So I think I did something wrong that doesn't allow me to boot up back to the home screen successfully.  Even when I built stock AOSP and loaded it I still got the same start-up error I talk about above.  

I followed the instructions found at: http://rootzwiki.com/topic/15145-build-overrides-on-pure-aosp-builds/ thinking that if I just fake out the build.prop everything will just verify fine.  This did get rid of the error when the framework starts up fine, but this didn't resolve my current issue when I lock the boot loader.  

I noticed flags in fstab.dragon that said to verify system and vendor.  I removed them, but again it didn't seem to do anything extra for me at boot time.  I'm sure I'm doing something wrong, lol

Basically my goal is to take a Pixel C and be able to flash it with custom software.  Then the company I work for wants to distribute them out to customers.  Warnings about the OS being unverified or the boot loader is unlocked is scary to no technical people so we don't want to show it even though we know it's ok.  It's about customer experience, right?

I assumed locking the boot loader would remove the wait for 30 seconds screen, but this is not be the case as you said.  So a lot of this effort could be for nothing.  I will have to try your original solution of editing ActivityManagerService and maybe this will fix my boot up issue when locking the boot loader.

Thanks,
-Brian

Anushree Ganjam

unread,
Feb 22, 2016, 10:29:03 AM2/22/16
to Android Building
Hi Douglas,
Is the sim card working well now?
What changes did you follow?
1) Now the /system/vendor points to /vendor. Symlink is created. But still sim card is not detected.

Jared Tsai

unread,
Mar 29, 2016, 10:53:38 AM3/29/16
to Android Building
Hi Douglas,

   Have you solved your issues?
   I also encounter the same issues in Nexus 5X (bullhead).

   Could you please help to share your solution? Thanks.

Best regards,
Jared.

Anushree Ganjam於 2016年2月22日星期一 UTC+8下午11時29分03秒寫道:

Andy Mou

unread,
Apr 2, 2016, 1:55:13 PM4/2/16
to Android Building
Hi Douglas,

Can you share you solution? Beside the sim card not detected, my time is backing to 1970 after reboot!

在 2016年3月29日星期二 UTC+8下午10:53:38,Jared Tsai写道:

Thomas Le Guevel

unread,
Apr 5, 2016, 10:32:23 AM4/5/16
to Android Building
Same issue as the original post from Douglas with Nexus 5x and build :
MHC19Jandroid-6.0.1_r22
Bluetooth KO
SIM card not detected

I tried what Hamilton recommended (flash factory first and then aosp) but does not change the result.
I am very surprised that Google does not let developpers build a clean AOSP with full-feature.

Still looking for a solution to get my SIM+BT working...

Olivier G.

unread,
Apr 27, 2016, 12:41:02 PM4/27/16
to Android Building
I built MHC19Q for Nexus 5X and have same issue: no SIM card.
Does anybody make some progress ?
It seems that several executables and libraries are missing in AOSP build compared to factory image (qmuxd for instance).
Moreover, "adb logcat" shows a reccurent error:
07-03 02:29:35.143   448   465 E QC-QMI  : qmi_client [448]: unable to connect to server, errno=[2:No such file or directory], attempt=22
Probably a problem with the Qualcomm processor (qmi=Qualcomm MSM Interface ?)... or a missmatch between the RIL and the modem firmware ?

I will continue to investigate but it looks strange that radio features are not working in AOSP (MHC19Q is the 10th build for bullhead...)

Jared Tsai

unread,
Apr 28, 2016, 10:04:44 AM4/28/16
to Android Building
I found a solution in the github.

The script will download a Google factory image, extract necessary files, and create a vendor folder for aosp.
Move the created vendor folder to aosp root and build the images again, the vendor.img will be in the out folder.
Just flash all the images into device, the radio works as normal.


bechts...@gmail.com

unread,
Apr 28, 2016, 10:04:49 AM4/28/16
to Android Building
Repo here explains the root cause of your issues and provides an automation solution to generate vendor blobs in AOSP compatible makefile structure that does not require any further changes in the source tree.

Thomas Le Guevel

unread,
May 4, 2016, 10:15:04 AM5/4/16
to Android Building
I confirm, it works :) build MHC19Q on Nexus 5x. Both BT and Cellular connectivity works now.

Oli Witzki

unread,
Aug 30, 2016, 7:19:28 PM8/30/16
to Android Building, thomasl...@gmail.com
Did you use the master branch for the AOSP build or a specific branch like MHC19Q?

dtste...@gmail.com

unread,
Nov 17, 2017, 8:02:31 PM11/17/17
to Android Building
Hi Brian,

I have the exact same problem.

Trying to build a pixel-c with prebuilt libraries in vendor.img, but build is failing with:
Check module type: out/target/product/dragon/obj_arm/SHARED_LIBRARIES/libzrp_intermediates/link_type
FAILED: out/target/product/dragon/obj_arm/SHARED_LIBRARIES/libzrp_intermediates/link_type 

I am guessing it is to do with libraries linking to other libs in system partition can not be packed in vendor partition.
Were you able to generate custom vendor.img and make it work after flashing?

Appreciate any help! Thanks!
Reply all
Reply to author
Forward
0 new messages