Re: [android-building] How to maintain android binaries checksum intact. after rebuild of AOSP.
We work pretty hard to make sure that the contents of the system image don't change unless the source tree is changed, and AOSP master should be in pretty good shape, although bugs do creep in sometimes. The build time and build number are stored in system/build.prop and change on every build though. The build number can be fixed on the command line with m BUILD_NUMBER=12345, but there is currently no way to fix the build date. You would need to edit build/make/tools/buildinfo_common.sh to not use $DATE to get the current timestamp. We would accept patches that made the build date settable from the command line. On Fri, Dec 21, 2018 at 7:58 AM wrote: > Hi Android Experts, > > > >We need some help / information that, Is there any way > to keep android images (system.img, boot.img etc ) checksum [md5sum/crc32] > same even after fresh build or recompilation??. Even though without > changing a single bit in the AOSP Source code if we rebuild it, Android > binaries checksum keeps changing. As I can understand that the > compilers/linkers adds the date and time-stamp to the images/binaries after > each build which causes the change in the checksum. So my question, Is > there any way to avoid this change in image checksum after every rebuild. > it should change only when we change any source code. kindly update. > > -- > -- > You received this message because you are subscribed to the "Android > Building" mailing list. > To post to this group, send email to android-building@googlegroups.com > To unsubscribe from this group, send email to > android-building+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-building?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Android Building" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android-building+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] AOSP flashing Pixel 3 XL with fastboot
I am trying to flash my Google Pixel 3 XL with my locally built AOSP. The build and flash seem to go smoothly, but the phone does not start up. At startup, the Google logo is seen shortly and then the phone boots again. I do not think there is anything wrong with the phone. When the phone is flashed with a factory image (crosshatch-pq1a.181205.006-factory-96b23504), everything works fine The AOSP repository has been retrieved with repo init -u https://android.googlesource.com/platform/manifest -b android-9.0.0_r21 --depth=1 compilation seems to work fine, flashing with fastboot -w flashall also completes without problems, but the phone doesn't start up. The interesting thing is that I have previously built an AOSP for a Pixel XL and that went fine, so it looks like some strange difference between Pixel and Pixel 3. I realize that there is a previous thread on something similar https://groups.google.com/forum/#!topic/android-building/lmCUWEgoaKQ but it was not clear what could be done to solve the problem. Any feedback would be highly appreciated. -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] Re: Emulator Out of Date and x86 based android virtual device error on AOSP.
Using aosp_x86_64-eng, still not work. 在 2017年4月30日星期日 UTC+8上午12:28:10,Chih-Wei Huang写道: > > > > Imran Khushwaqt於 2017年4月26日星期三 UTC+8上午11時15分03秒寫道: >> >> HI, >> I have synced AOSP master and build successfully. Using these commands. >> Make clobber >> >> lunch aosp_arm-eng >> >> emulator. >> >> >> Emulator starts up with message "*Running an x86 based android virtual >> device (AVD) is 10x Faseter. We strongly recommend creating a new AVD*". >> >> and On console it says* AVD is out dated. Please update using android >> studio*. An other message with emulator commands pops up is "*Could not >> detect * >> >> *an ADB binary. Some emulator functionality will not work until a custom >> path to ADB is added in the extended settings page.*" >> >> > > As it said, use the x86 emulator instead of arm. > > > lunch aosp_x86-eng > > > or if you prefer the 64-bit OS: > > lunch aosp_x86_64-eng > > > > > >> My Question is how can I create new AVD and add it to build path during >> lunch or make command or add custom path in extended settings >> >> page to avoid these error and make AVD faster. >> >> >> What I have tried is >> >> Open android studio and updated all AVD in android studio sdk directory. >> This doesn`t worked and then I changed sdk path in android studio >> >> to AOSP WORKING_DIRECTORY/sdk and updated the installed packages. But still >> its not working and emulator takes around one and half hour >> >> or two to start. >> >> What can I do to make it fast. I am using Mac OS 10.12 with 1.5 GHZ core i5 >> with 8 GB of RAM. >> >> -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] How to maintain android binaries checksum intact. after rebuild of AOSP.
Hi Android Experts, We need some help / information that, Is there any way to keep android images (system.img, boot.img etc ) checksum [md5sum/crc32] same even after fresh build or recompilation??. Even though without changing a single bit in the AOSP Source code if we rebuild it, Android binaries checksum keeps changing. As I can understand that the compilers/linkers adds the date and time-stamp to the images/binaries after each build which causes the change in the checksum. So my question, Is there any way to avoid this change in image checksum after every rebuild. it should change only when we change any source code. kindly update. -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.