hi,
I have downloaded froyo source from google and trying to build and run it on nexus one (N1). N1 is untampered (locked bootloader/non-rooted/original recovery image).
I followed the build steps as given at google website with required modifications.
I got one build error about librpc.so needed by libgsp.so. Resolved it by building librpc.so mannually and then continuing the build.
OTA package was created successfully. But when I put the zip as update.zip on sdcard and try to update from recovery, I get signature verification failed error.
Exact error is:
-- Install from sdcard...
Finding update package...
Opening update package..
Verifying update package...
E:failed to verify whole-file signature
E:signature verification failed
Installation aborted
Anyone knows whats going wrong?
If I do the update process with zip provided by Google (signed-passion-ota-43546.cc653ee4.zip) then it works.
Is unlocking the bootloader is required if you want to use custom build image?
Does google use different key to sign its packages than the one available at (build/target/product/security/testkey.x509.pem) by any chance?
Your packages would either not be signed at all, or would be signed with test keys.
These test keys aren't accepted by the stock recovery environment on the N1.
You would need to root your N1, install a custom recovery, and sign the OTA zip with test keys for this to work.
There is no way to sign update packages with Google's private keys.
Thanks for superfast reply. Didnt expect it will be so fast.
My zip was signed. Problem seems to be the locked bootloader and private keys as you said.
I was a bit reluctant to root my N1. Guess i dont have any other option now
I have one doubt. If I install a custom recovery and then update using custom built update.zip, wont the recovery image get overwritten by the recovery image in the update package?
virajk said:
I have one doubt. If I install a custom recovery and then update using custom built update.zip, wont the recovery image get overwritten by the recovery image in the update package?
Click to expand...
Click to collapse
I guess recovery folder from the OTA package should be removed and then the zip should be signed again and used.
Could also do the steps below that are from here:
23) In your terminal, type "rm /system/etc/install-recovery.sh" and hit Enter
24) In your terminal, type "rm /system/recovery-from-boot.p" and hit Enter
Or probably just what you said above.
built librpc.so by hand?
I am getting the same error you mentioned:
ld: warning: librpc.so, needed by out/target/product/passion/obj/lib/libgps.so, not found
You say you built it by hand -- can you provide more explicit instructions for doing this? Thanks.
-sbq
Give command "mm librpc" to build rpc alone. And then continue the make of full android. I had got this error while building cyanogen's source also.
can anyone help me ?
i got this error while building
http://pastebin.com/9dVJJA4y
If you are missing libgps or other files, that is because you did not run or completely finish the extract-files.sh script found in device/htc/passion
edit: alternatively you can use unzip-files script with a froyo update.zip
Error which MrNameless is facing does not look like because of any missing libgps or any other library. it is a compile error.
The error regarding libgps.so which sbq and myself faced is not becasue of missing libgps.so. This error is mostly because of a missing dependancy.
Refer: http://osdir.com/ml/android-platform/2009-02/msg00106.html
Regarding getting build from google source to work on nexus one, I could load the new OTA package after unlocking the bootloader. But it doesnt boot. Looks like system hangs during boot. Will try to see if I can see the boot log. Should be possible I think.
Meanwhile I built package from cyanogen's source. It works perfectly.
Re: missing libgps.so is NOT an extract-files.sh issue
jazzor said:
If you are missing libgps or other files, that is because you did not run or completely finish the extract-files.sh script found in device/htc/passion
edit: alternatively you can use unzip-files script with a froyo update.zip
Click to expand...
Click to collapse
That is not correct. If you look at extract-files.sh (i.e., open up the file in an editor), you will see the list of files it gets from the Nexus One. librpc.so is not one of those files.
If you look at the android-building google group, you'll see a post by Jean-Baptiste Queru on Jul 14, 10:33am that addresses this (librpc.so) problem.
I used the solution "mm librpc" posted by virajk and it worked for me.
-sbq
virajk said:
Regarding getting build from google source to work on nexus one, I could load the new OTA package after unlocking the bootloader. But it doesnt boot. Looks like system hangs during boot. Will try to see if I can see the boot log. Should be possible I think.
Meanwhile I built package from cyanogen's source. It works perfectly.
Click to expand...
Click to collapse
After receiving the OTA update to FRF91 I ran extract-files.sh. I then built from the Google source with only the perviously-mentioned librpc.so problem. I flashed my image onto the phone using fastboot. It came up, but got into a loop during boot. See JBQ's Jul 14, 4:38pm posting to the android-building google group (and my reply) to see the solution.
Related
When scripting a ROM is there a way to verify the a certain version of recovery is installed before flashing?
Thanks!
Hmm, that is a good question. I don't think it can and even if it could, with the limitations in the edify scripting, it would be very hard to. For example, on the EVO 4G, I wanted to make it check what device you were running and what kernel you were using but it was such a PITA to even attempt that I just gave up. What made it even harder was that recovery uses it's own kernel, so trying to find out info from the kernel you were running was impossible.
That would be cool, some form of a incompatibility check.
Does getprop return anything while in recovery?
Must be possibly if ROM Manager can do it.
Edit: NM, sorry, I didn't properly read the OP.
Sent from my PG86100 using XDA Premium App
myn said:
Does getprop return anything while in recovery?
Click to expand...
Click to collapse
Not sure?
-viperboy- said:
Hmm, that is a good question. I don't think it can and even if it could, with the limitations in the edify scripting, it would be very hard to. For example, on the EVO 4G, I wanted to make it check what device you were running and what kernel you were using but it was such a PITA to even attempt that I just gave up. What made it even harder was that recovery uses it's own kernel, so trying to find out info from the kernel you were running was impossible.
Click to expand...
Click to collapse
Thats sorta what I am trying to do! At least I am not alone in this quest.
scrosler said:
When scripting a ROM is there a way to verify the a certain version of recovery is installed before flashing?
Thanks!
Click to expand...
Click to collapse
i don't think there is a definite guaranteed method .. although maybe somebody will prove me wrong as i might be thinking through it too much.
i dont have adb access to verify anything yet, but here is my line of thought.
the recovery binary, generally stored in /sbin/recovery won't really have a stamped version number on it, although you might be able to strings the binary for a version number, which could be executed by a .sh script called by the updater-script and if the script fails, you can stop the update and print an error message.
another thought, the kernel the recovery binary is housed in that is flashed/stored on the recovery partition won't really give much indication as the kernel will probably always be the same kernel version (2.6.35 or whatever is easiest to build for device support), but its compile number might increase, assuming they didn't just merge a new /sbin/recovery binary into the ramdisk and merge with an existing zImage (which could happen).
I've seen manufacturer OTA updater-script files and even cm7 verify device product.model using assert and getprop to confirm the correct .zip is being applied to the correct device before allowing the ROM to be flashed. any official OTA should have this assert getprop command at the top as well as any cm7 .zip.
unfortunately none of those methods or approaches will tell you which version of recovery is being used as twrp, amon and koush all use arbitrary (only really internally significant) version numbers for their recoveries.
on a more positive note, it is possible to test for some types of support in a recovery before allowing an updater-script .zip file to be loaded.
in an effort to better understand and perhaps take an alternate route to provide a solution, what are you trying to accomplish, i.e. what type of support are you requiring from the recovery?
myn said:
Does getprop return anything while in recovery?
Click to expand...
Click to collapse
it should but i can't prove it w/o adb access. i'm pretty positive manf OTA .zip files and cm7 .zip use assert(getprop(ro.product.model="supersonic")) etc to check before they allow the .zip to load .. but i'm thinking ro.product.model should be pulled from /system/build.prop which might/might not be mounted in recovery mode when the .zip is being loaded or stored else where when the updater-script is being executed?
should be easy enough to test with adb access to recovery ....
EDIT: adb access now:
cwm recovery on evo 3d, getprop is not setup in the shell and does not work.
taken from the NS4G OTA released a week or so ago:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.4/GRJ22/121341:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.5/GRJ90/138666:user/release-keys");
assert(getprop("ro.product.device") == "crespo4g" ||
getprop("ro.build.product") == "crespo4g");
if the call to file_getprop mounts /system, then the second call to getprop should read from the same /system/build.prop. otherwise the stock recovery would have to support the getprop command, which i doubt as the first command differs from the 2nd.
hope that makes sense. looks like assert(file_getprop( is your best bet .. and that doesn't verify recovery version. if you can provide more information around what you're wanting to do, perhaps there is another way to approach.
hope that helps!
Interesting...
How about just asking if that is possible in scripting. If twrp then else...., just an idea or if recovery is at a fixed location...read binary to see a signature? Check the md5 and see what it belongs to? You bad boy is my daily driver!
life64x said:
How about just asking if that is possible in scripting. If twrp then else...., just an idea or if recovery is at a fixed location...read binary to see a signature? Check the md5 and see what it belongs to? You bad boy is my daily driver!
Click to expand...
Click to collapse
I don't know if you've ever looked at an updater-script but it's not like standard scripting. I guess you might be able to extract a shell script and run it to check for some identifying information in recovery and have it report back the results in a ui_print but it would be a pain in the balls IF you could get it to work.
-viperboy- said:
extract a shell script and run it to check for some identifying information in recovery and have it report back the results in a ui_print but it would be a pain in the balls IF you could get it to work.
Click to expand...
Click to collapse
the part that would be a pain, as viperboy eludes to, is creating an index of the recovery versions, example:
md5sum: 029jlaksdfl232l34jklas = twrp recovery 1.0.0
md5sum: 0djlsdkj23lkj423lkjasdfl = twrp recovery 1.0.1
md5sum: lksd0923jlszdf092034 = twrp recovery 1.0.2
and doing that for each version of the recovery being released in addition to also indexing cwm recovery. sure, its doable ... is it practical?
the list would need to be updated with each new version of a recovery that is released, otherwise an installing ROM wouldn't know which version a new recovery was.
the OP never answered my inquiry as to what exactly he is looking for in the recovery, a specific feature or function? without knowing the full story, its hard to say this is the best approach.
Never did look up updating script. Just trying to give ideas out of the box. It seems limiting.
life64x said:
Never did look up updating script. Just trying to give ideas out of the box. It seems limiting.
Click to expand...
Click to collapse
in my opinion, i'm not sure its a limitation of edify (updater-script) or a limitation of bash/sh/shell scripting (which edify can leverage) but more of a limitation in how custom recovery's are designed and versioned. provided android wasn't really designed to have many different versions of custom recovery's on one device, there aren't really any APIs setup for version control in the recovery .. in fact very little is supported in recovery as its just that ... a temporary recovery mode.
the method i mention above, hash'n out each version and storing in a table/index, would be one approach to implementing a type of version control w/o the custom recovery developer's changing their approach.
imo, the ideal approach would be for the custom recovery developers to implement a type of version control all custom recovery's follow, but since its not really *needed* or popularily demanded, i dont think that concept has a very high likihood of that occuring in the near future.
edify (updater-script) and bash scripting are both pretty decent languages and i think bring a very good set of features and abilities to the table, given the scope android originally designed the recovery mode for.
if for whatever reason you want recovery to support other languages or more features, i know twrp has a github where they track issues, put in a request or fork, code and send a pull request to their git. likewise i'm sure koush is open also.
the skys the limit!
Hello,
I want to compile Android from source. I want to just build a fully default Gingerbread that would run nice on my phone. I got the Android source, kernel source (kernel-2.6.32-U8800-Froyo) and now I don't know what to do next. I compiled the generic one already (lunch full-eng) and it ran fine on the emulator.
My most important question is, if I make it otapackage and flash it, would it start? If it doesn't, can I recover? What folders/files are essential if I make my own device for example in "device/huawei/u8800"
Also, where can I find a GOOD porting guide? I have found some that are old and not used anymore.
Some links
Start by going through source.android.com for the general basics if you havent already.
Also, even though Google removed the PDK (Platform Developer's Kit) from the site, it has been mirrored on kandroid here: http://www.kandroid.org/online-pdk/guide/index.html
The stuff in the the PDK, although inadequate, is still very important and explains how to create the necessary makefiles to add to the build, configuring for a new market, etc. etc.
Also,
watch these two videos over here. These were very helpful in my ROM development:
http://www.youtube.com/watch?v=1_H4AlQaNa0
http://www.youtube.com/watch?v=rFqELLB1Kk8
Learn to use github. It is helpful for you to keep track of your changes as well as incorporate others works into your own.
http://help.github.com/
Finally, Cyanogenmod repos are your BEST friend. Almost all major AOSP ROM devs owe some sort of thanks to those guys who have done so much. If you want to check out some of the code changes and patches that you want to incorporate look here on their gerrit:
review.cyanogenmod.com
If you want to look at the other changes that are actually in the cyanogenmod builds, best to look at their git repos here:
https://github.com/CyanogenMod
I am still learning right now while I create my ROM but your welcome to PM me if you have any questions
Glad someone helped. Now that ICS is available, I will build that instead. Now, I will follow the kandroid tutorial and add hardware_msm7x30 from cyanogenmod's repos. Then I'll make my own makefiles in the huawei/u8800 and I'll see if that works.
Also, some things I am not still clear. If I am not adding any recovery files, it shouldn't replace it, right? I want to make sure I can recover. However, my phone has a bootloader mode, which should still work, even if other's messed up. And the kernel, if I already have a compiled kernel for android 2.2, should it work for newer versions?
Thanks
Well AOSP as far as I know adds the stock recovery into the build so if you have a stock ROM, then you will lose your recovery (unless you change the source to skip the adding of recovery to otapackage).
Your bootloader should be fine. so you will theoretically be able to re-flash a custom recovery with fastboot as long as your bootloader is unlocked (assuming your phone is already rooted and has a custom rom, then it should be unlocked)
If you are using CM7 as base, then you dont have to worry about it as it is configured to NOT replace the recovery during the building and creating the otapackage.
The kernel should not be compatible as there were significant changes from Froyo and you should not use it. By the way, for now, work on the ROM first. Creating a custom kernel from scratch is hard work and should be left as the last task to do (assuming you know linux kernel development). Just use the stock pre-built kernel that comes with the source.
Also, according to Google:
Starting with IceCreamSandwich, the Android Open-Source Project can't be used from pure source code only, and requires additional hardware-related proprietary libraries to run, specifically for hardware graphics acceleration.
Click to expand...
Click to collapse
This means you need to find the correct hardware drivers first. Where to find that is beyond me. Check CM repos. It would be easy if everyone had a Nexus S/ Galaxy Nexus as the drivers are immediately available on source.android.com. Ah...well....
Personally, I am going to wait a few weeks before dabbling into ICS ROMs. Wait till CM7 comes out with a nightly for my nexus one and then rip the drivers from their ROM and use it for mine
I got ICS source and made the necessary Android.mk, AndroidProducts.mk, BoardConfig.mk and u8800(my device).mk, also vendorsetup.sh . Now, when I am trying to build it doesn't give me an error, more of a suggestion. It says to include "LOCAL_MODULE_TAGS := optional" in the hardware/msm7k/liblights/Android.mk. I added that, and tried again. Got that message again, but with other type /libril/Android.mk
About fastboot, I am not sure if my device has that. It can be turned on with volume up and down + power, but it boots to so called "pink screen". When I mount phone using usb to my pc, I can browse the recovery.img and other related stuff. If I have the otapackage, can I just take the recovery out from there or what should I modify in source? Add something to the makefiles?
Yeah I am pretty sure you should add the LOCAL_MODULE_TAGS to all of the relevant pre-built files. maybe they made the compiler less harsh in ICS when compared to the one for gingerbread. In gingerbread, it outright crashed the compile and asked you to add the tags.
According to Google engineers, here is the reason why they use these tags:
Short answer: lack of time.
The urgent concern was to prevent new modules from using a user tag
(implicitly or explicitly), and we took care of that. We haven't had
time to deal with the existing modules, there are over 1000 of those.
JBQ
Click to expand...
Click to collapse
By the way, I hope you have git setup and the changes you have made are being staged and commited to your repo in github. If you ever make a mistake that hardcore crashes your compile and you dont know what you did, git will be there for you to rollback the changes as well as keep track of everything you have done from commit to commit
As far as I know, CM repos dont have everything complete for a full build of ICS but I could be wrong.
So you are working with AOSP correct?
As for the fastboot every android phone should have a fastboot by default but I believe each phone has a slightly different version. I will post how my fastboot looks like in a bit.
As for the removal of recovery, there should be somewhere in either source, makefiles or argument for the otapackage command that should leave out the recovery when making update.zip. You could just remove the recovery from the update.zip, change the updater-script and repackage it but its not a clean solution and those changes should be done in a uniform manner so you dont repeat this step every time you do a new build.
Where exactly is it, I have yet to know. Still learning much of this myself.
I now completely understand what modes of turning on my phone has... First one is normal, second is recovery, third is update-bootloader(I can access all files with it too) and four being the fastboot. The custom recovery I have on has an issue that it wants to boot to charging mode when I type "adb reboot bootloader". I can get to fastboot with the custom ROM I have on right now though. I think I am safe if I have issues.
I edited msm7k Android.mk to remove libaudio and libgralloc (errors with those), and it compiles to the step where it says it has no rule to make kernel requied by boot.img. I have put into BoardConfig.mk the line TARGET_PREBUILT_KERNEL with my kernel. I don't understand, what's wrong now...
My goal is to simply get it booting up. I'll look into libraries and other later.
-e-
Got the kernel thing sorted out. Copied device.mk from tuna device and edited to fit my device. Also modified full_u8800.mk and made the call to inherit from device.mk. Compiling now and I think I got past that.
-e2-
Got it built successfully. Fastboot won't let it install, because it has no mount points. Added mount points and let's see...
Nice to see you are making progress.
Got it built, but the fastboot is kinda buggy in my device, maybe custom rom issue. I can't make otapackage, it says "no rule to make target otapackage". I have a possible fix, trying that later.
Otherwise, I read its possible to flash system.img from recovery via advanced restore, update.zip package or advanced flash_image, but I don't know. Will post results.
Sent from my u8800
-e-
Tried make otapackage again. It still says "make: *** No rule to make target `otapackage'. Stop.". Maybe some things are still missing, I don't know. adb flash_image command will always post -1 to me, update.zip didn't work, advanced restore is not for this. I have a compiled image and I can't wait to test it, but I can't flash it...
If nothing works I'll revert to stock ROM and try again.
Blefish said:
Got it built, but the fastboot is kinda buggy in my device, maybe custom rom issue. I can't make otapackage, it says "no rule to make target otapackage". I have a possible fix, trying that later.
Otherwise, I read its possible to flash system.img from recovery via advanced restore, update.zip package or advanced flash_image, but I don't know. Will post results.
Sent from my u8800
-e-
Tried make otapackage again. It still says "make: *** No rule to make target `otapackage'. Stop.". Maybe some things are still missing, I don't know. adb flash_image command will always post -1 to me, update.zip didn't work, advanced restore is not for this. I have a compiled image and I can't wait to test it, but I can't flash it...
If nothing works I'll revert to stock ROM and try again.
Click to expand...
Click to collapse
If you successfully compiled, take the boot.img and system.img and package them into a zip and use dsixda's kitchen to make it flashable
Blefish, is it possible for you to share your device/vendor structures somewhere? I just finished setting up a build machine for ICS (using Cyanogenmod's repos in my case), and made a working full-eng image that seems to boot just fine in the emulator, so I'm seemingly all ready to hack around our device's specifics. But I would rather not do duplicate work, so I decided to ask
I'm also grabbing Huawei's new 2.6.35-based package to get the new kernel config, can't wait for them to release the actual sources for the update.
I'll share them on GitHib once I get a working build. I haven't got much time, and I changed to CM9 alpha now (repo branch ics). Since we got a 2.3 update, my first task is to port the latest clockworkmod recovery and then the ICS.
Compiling Android is long task and I'll do it in weekends, but the recovery should be available sometime, it shouldn't be hard to port that.
Oh yeah, look up stockwell's, dzo's and genokolar's github, they have done the device configuration. You can get much help from there. This weekend I'll propably test the build, I got otapackage command working now (it needed some things I can't write on mobile).
Sent from my U8800 using Tapatalk
LIke the title says, this rom is built from the 4.4.2_r1 image and binaries from the Google repository (no changes or mods). This is pure AOSP KitKat.
This rom contains AOSP versions of Gallery2 and Camera2 which does not contain Google features such as HDR+ or PhotoSphere.
To install:
-TWRP or CWM recovery
-Factory reset, wipe cache and dalvik...if coming from a rom other than stock, wipe data too.
-Flash Rom
-Optional....flash "Photosphere Camera Addon Module" or other "Gapps packages"...only necessary for HDR+ and Photosphere
-Reboot and let install
-For HDR+ and Photosphere, flash "Photosphere Camera Addon Module" right after flashing rom (make sure its for 4.4.2) *see below for link
Rom Download.
aosp_hammerhead-kot49h MD5=34d9d60a4062d590f92746c977af9167
https://mega.co.nz/#!DJkD2QLB!OvMrzzp023VJYJSu-Y0wplRuL6Qlt3oDKNr6DtshoEw
Photosphere Camera Addon Module and all other Gapps-PA-Google apps
http://forum.xda-developers.com/showthread.php?t=2397942
To root-SuperSU 1.86
http://download.chainfire.eu/372/SuperSU/UPDATE-SuperSU-v1.86.zip
-Flash rom, let it install, place SuperSu into internal storage, reboot to recovery flash and reboot.
Thanks to Google for images and binaries
Thanks to TKruzze for PA-Google apps
Thanks to Chainfire for SuperSU
first... first time
will give it a shot.. lets go
Nice to have solid stock to fall back on. Thanks
Sent from my Nexus 5 using XDA Premium 4 mobile app
So what has been done with this besides just building from source? It's not clear whether or not gapps are added. How was the installer generated?
Gene Poole said:
So what has been done with this besides just building from source? It's not clear whether or not gapps are added. How was the installer generated?
Click to expand...
Click to collapse
Nothing. No gapps necessary.
What do you mean how was the installer generated???
Loving all this new development. Thanks for this
sent from my Hammerhead Nexus
rsa 329 said:
Nothing. No gapps necessary.
What do you mean how was the installer generated???
Click to expand...
Click to collapse
When I build, I get system.img, recovery.img, etc. No installer zip.
My builds seem to be missing some critical components or binary packages. That's why I asked if you added anything, or if you did like me and just followed build instructions here:
http://source.android.com/source/building.html
Gene Poole said:
When I build, I get system.img, recovery.img, etc. No installer zip.
My builds seem to be missing some critical components or binary packages. That's why I asked if you added anything, or if you did like me and just followed build instructions here:
http://source.android.com/source/building.html
Click to expand...
Click to collapse
There is better instruction than what you have there. Later, when I'm near my PC I will pm you and give you some links to better instruction.
Also, before I make I add the binaries from the repo.
Thanks, RSA, for the info in your PM. I got a compile that works, but only for 10-12 hours. After that, the cell provisioning breaks. "No Service" and nothing I can do short of a reboot brings it back. I thought it might be my build, so I installed yours. Same thing. It very well may be something broken on my part, like APN or something (I'm using the stock APNs from the AOSP source) since neither my build nor yours are working right. I needed my phone so I restored factory before I could dig through logcats.
Any ideas? Anyone else running this build fulltime? I'm AT&T if that matters.
Gene Poole said:
Thanks, RSA, for the info in your PM. I got a compile that works, but only for 10-12 hours. After that, the cell provisioning breaks. "No Service" and nothing I can do short of a reboot brings it back. I thought it might be my build, so I installed yours. Same thing. It very well may be something broken on my part, like APN or something (I'm using the stock APNs from the AOSP source) since neither my build nor yours are working right. I needed my phone so I restored factory before I could dig through logcats.
Any ideas? Anyone else running this build fulltime? I'm AT&T if that matters.
Click to expand...
Click to collapse
Interesting. I've been using a debloated version of my aosp for a while now with no problems. I ran this build for a couple weeks before switching and had no issues. Did you do a full wipe? How about ART, are you using art or dalvik? Have you tried your build after doing a system format? What service provider do you use?
Sorry for all the questions, just trying to get an idea of your situation.
I'm with AT&T. I decided to put this back on and wait for it to act up, then get a logcat and go from there. We'll see how it goes.
I've been running this for 3 days now without issue. The only change I made from my first attempt was to: install only the system partition (no recovery or boot); use my own boot image that has some things I need in it(1); and install the latest PA-GApps over it after installation. None of those changes should have negated the behavior I was seeing earlier, so I'm writing it off as odd coincidence.
1. I have modified the boot image to include stuff for mounting external storage to the USB port. This also includes a modified framework-res.apk and SystemUI.apk compiled on my system and inserted at install time to the system partition.
Gene Poole said:
I've been running this for 3 days now without issue. The only change I made from my first attempt was to: install only the system partition (no recovery or boot); use my own boot image that has some things I need in it(1); and install the latest PA-GApps over it after installation. None of those changes should have negated the behavior I was seeing earlier, so I'm writing it off as odd coincidence.
1. I have modified the boot image to include stuff for mounting external storage to the USB port. This also includes a modified framework-res.apk and SystemUI.apk compiled on my system and inserted at install time to the system partition.
Click to expand...
Click to collapse
Very cool! Glad to hear you got it working.
One issue I've just discovered is that the camera, when in video mode, records video files with a green line at the bottom (only visible on playback). I've researched this and found that AOSP source is missing an update in one of the files that makes up the libmmcamera_interface.so shared object. Copying the same filename from the factory image into the /system/lib directory, overwriting the existing file from AOSP build fixes the problem.
Again, no problem with your build; the problem seems to be that Android hasn't committed all their code the the AOSP tree.
rsa 329 said:
There is better instruction than what you have there. Later, when I'm near my PC I will pm you and give you some links to better instruction.
Also, before I make I add the binaries from the repo.
Click to expand...
Click to collapse
Hi RSA,
can you please share the instructions with me as well ? much appreciate your work..
I've been using CM12.1 for couple of months, love it. Found some bugs and waited a few nightlies (few weeks per "nightly") and after that tried to make a bug report.... not accepted, because CM12.1 is not developed anymore. CM13 is not available for Z2, so I tried to build CM13 myself, following the guide found on cyanogenmod site. Sorry, as a new member, can't link that URL here... It fails... I have gone past that point to extract the proprietary "blobs" from my phone (running the mentioned CM12.1) and tried again the breakfast sirius command. I'm unable to paste results here, because being a new member... look the result from pastebin com with /mwBfxHEL behind the URL...
The reason seems obvious, missing that msm8974-common-vendor.mk file. Can't find it on my computer using "locate". Can't find it using google. Don't know how to fix this or get past this... Any help appreciated!
Nobody has build CM13 for Z2???
The issue you are describing likely results from the blob extraction for msm8974-common not operating correcty: Please execute (or re-execute) the extraction scrip in this folder of the device tree as well (should be device/sony/msm8974-common). Could you paste the output after running that script, please?
Diewi said:
The issue you are describing likely results from the blob extraction for msm8974-common not operating correcty: Please execute (or re-execute) the extraction scrip in this folder of the device tree as well (should be device/sony/msm8974-common). Could you paste the output after running that script, please?
Click to expand...
Click to collapse
OK, that advice helped. Tried 'breakfast sirius' again, it went longer, complained about something missing in shinano-common folder. Used your approach again and got past that one too. After that, 'breakfast sirius' succeeded. I tried 'brunch sirius' and it failed. Tried it again, it got longer before failing again... did "while [ $? -ne 0 ]; do !! done" to try building until it succeeds. After quite a while, I stopped it, ran brunch sirius command and copied the output to pastebin.
Take a look at pastebin.com/Qz4hq1aZ
Something about libta.so?
Flexy75 said:
OK, that advice helped. Tried 'breakfast sirius' again, it went longer, complained about something missing in shinano-common folder. Used your approach again and got past that one too. After that, 'breakfast sirius' succeeded. I tried 'brunch sirius' and it failed. Tried it again, it got longer before failing again... did "while [ $? -ne 0 ]; do !! done" to try building until it succeeds. After quite a while, I stopped it, ran brunch sirius command and copied the output to pastebin.
Take a look at pastebin.com/Qz4hq1aZ
Something about libta.so?
Click to expand...
Click to collapse
Should I extract the blobs from a Z2 with OEM firmware? I vaguely remember that TA refers to something to do with DRMs that you lose when you unlock the phone to be able to install other firmwares...
Sorry for the delay.
This is an issue with the vendor files. I think that th extrction scripts are somewhat outdated, or didn't the extraction script didn't find some files. There should be a repo on github which should provide you with the needed files. Another possibility would be to extract and mount the system image of a stock and let the script process these files (there is a cmdline switch for pointing the script to it: please have a look into this script for the according switch).
Hope this helps.
Diewi said:
Sorry for the delay.
This is an issue with the vendor files. I think that th extrction scripts are somewhat outdated, or didn't the extraction script didn't find some files. There should be a repo on github which should provide you with the needed files. Another possibility would be to extract and mount the system image of a stock and let the script process these files (there is a cmdline switch for pointing the script to it: please have a look into this script for the according switch).
Hope this helps.
Click to expand...
Click to collapse
OK, found the repo. Got all the files, got the build to succeed! Thank you very much! Just few more questions... There is not just one zip file in the directory... which one to install? How do I install the zip file the build created? Perhaps via booting to recovery and installing it from there? And how does it behave? Like a upgrade, or a clean install?
I have really "screwed" up here. I erased everything on my TouchPad. So, how can I add the files I needed in order to get the rest of Android 9?
I have tried several files with TPToolbox (2015-01-08-v42) and did not get anywhere.
So, right now I could use some big help here. Without an OS, I cannot even get TWRP installed.
Thanks ahead for any help and support here.
BTW, I had Dirty Unicorn 8.1 before I erased everything. So I am really looking forward to this new version.
What does it show on the moboot menu when the TP is booted?
There was nothing, no software or moboot installed. I did finally manage to get TWRP installed (3.1.0.0) and during boot moboot version 0.3.8 shows up as well. So good for the great (really!) news.
But I now have a new problem, when I download load "du_tenderloin-v13.0-20190328-1316-RC.zip" the MD5 value does not match and it fails installation. I have tried 4-5 times on the downloads and still fails the MD5 value. I guess I'll wait till the next RC release or does someone knows where I can get a good release?
BTW- Thank you "HP_TOUCHPAD" for getting back to me. I really appreciate it. And to all the guys on this forum, especially a big thank you to Flintman for all that he has done .
How are you installing DU v13?
There is nothing wrong with the file from the site.
Using TWRP 3.1 0-0:
Select the flash zip file.
On the next screen in Options ( uncheck ) Zip signature verification.
The ROM will install with no issues.
HP_TOUCHPAD said:
How are you installing DU v13?
There is nothing wrong with the file from the site.
Using TWRP 3.1 0-0:
Select the flash zip file.
On the next screen in Options ( uncheck ) Zip signature verification.
The ROM will install with no issues.
Click to expand...
Click to collapse
_________________________________________________
I downloaded a "fresh" version of du_tenderloin-v13.0-20190328-1316-RC.zip (MD5 still did not match).
I made sure that "Zip signature verification" was unchecked and went ahead and installed it again.
During the installation I get the following error:
Flashing Dirty Unicorns System files...
E1001: Failed to update system image.
Updater process ended with ERROR: 7
Error installing zip file "/external_sd/ttinstall/du_tenderloin-v13.0-20190328-1316-RC.zip"
Updating partition details...
...done
I went ahead and re-boot the unit and it would only show the following:
moboot 0.3.8
boot TWRP
boot webOS Recovery
reboot
shutdown
For some reason I believe that the file is not coming down correctly (?) and because my MD5 does not match is the reason I'm thinking this.
Thanks for the support you are giving me.
The MD5 posted it for the 20190328 ROM is:
3fb70d72204ce4e8eef56fb4548930b6
I downloaded the 20190328 ROM and in Ubuntu did a md5sum on the file, the result:
89e32f1c6b5cf6792bf3ac6216c40a26
MD5 does not match.
Installed the ROM in TWRP 3.1. 0-0 after preparing the system for DU v13 as explain on this guide:
HP TOUCHPAD Optimize for Android with Swap Partition and SKZ Kernel_ Flash Files_
From the TWRP installation screen:
Installing zip file '/external_sd/du_tenderloin-v13.0-20190328-1316-RC.zip'
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
Warning: No file_contexts
The ROM finished the installation property
Question:
How was the Android partitions created before installing the DU v13 ROM?
Was the /system partition created of a size of 1.4GB or larger?
How was the Android partitions created before installing the DU v13 ROM?
Using "Wipe_All_and_Create_Android_with_Swap_Partition"
Was the /system partition created of a size of 1.4GB or larger? Yes, 1.7GB I believe.
So, I have started over again -
I re-booted and from MOUNT I Selected (checked) Cache, Data, System and Micro SDCard (some were not checked before)
Then I went back to Install and tried again.
Great! This time I get;
Flashing boot image...
script succeeded: result was [1.000000}
Updating partition details...
According the web page - ..."installed the ROM as always, there is nothing else to do..."
I then rebooted - booting into Android - Optimizing app xx of 120
Upon finishing I get the following error "Weather Information Pro...keeps stopping.
Also, I am unable to connect to the Play Store to update the Play Service app,
Showed that Android Play Store was outdated.
Tried to installed "open-gapps-arm-9.0-pico-20190405.zip" but it failed with the following error:
Error Code: 40 - Unmounting /system
My new question is: How do I install open-gapp to get the latest? And does open-gapp also installs
the Play Service app?
Again, thanks for all the help.
_dave said:
How was the Android partitions created before installing the DU v13 ROM?
Using "Wipe_All_and_Create_Android_with_Swap_Partition"
Was the /system partition created of a size of 1.4GB or larger? Yes, 1.7GB I believe.
So, I have started over again -
I re-booted and from MOUNT I Selected (checked) Cache, Data, System and Micro SDCard (some were not checked before)
There is no need to mount anything, the ROM will mount everything that it needs when flashing.
Then I went back to Install and tried again.
Great! This time I get;
Flashing boot image...
script succeeded: result was [1.000000}
Updating partition details...
According the web page - ..."installed the ROM as always, there is nothing else to do..."
I then rebooted - booting into Android - Optimizing app xx of 120
The basic ROM needs to be install, the ROM does not provide any Apps.
Why is Android Optimizing app xx of 120?
Did you installed or restore any extra Apps?
Upon finishing I get the following error "Weather Information Pro...keeps stopping.
How was the Weather Information Pro installed?
Also, I am unable to connect to the Play Store to update the Play Service app,
Showed that Android Play Store was outdated.
Did you restore an old version onto DU v13?
Tried to installed "open-gapps-arm-9.0-pico-20190405.zip" but it failed with the following error:
Error Code: 40 - Unmounting /system
My new question is: How do I install open-gapp to get the latest? And does open-gapp also installs
the Play Service app?
The proper way to have a working Tablet:
1. Using the Wipe_ALL_Create_Android_With_Swap ( DU v13, Android Pie needs a swap partition)
2. Reboot
3. Flash the DUv13 ROM and the version of open-gapp and the same time.
The best is to use the Variant Pico, is the basic and allows Play Service to install any Apps.
Click here to download the latest open-gapp
Again, thanks for all the help.
Click to expand...
Click to collapse
You are very welcome !
Hi HP_TOUCHPAD, I repeated your last steps (again) and FINALLY FULL SUCCESS!!! OMG - THANK YOU!
_dave said:
Hi HP_TOUCHPAD, I repeated your last steps (again) and FINALLY FULL SUCCESS!!! OMG - THANK YOU!
Click to expand...
Click to collapse
Good to know you were able to get your Tablet working. Keep an eye on the DU v13 on here as more enhancement will be posted it. Enjoy your all new again HP TP !