[android-building] Re: Android 9.0.0 Pie DR Released

['Bill Yi' via Android Building]

We have merged pi-dr1-dev into AOSP/master.

We have also pushed additional kernel projects for the following devices:
tag project branch  
 device
android-9.0.0_r0.33 kernel/msm-modules/qca-wfi-host-cmn 
android-msm-bluecross-4.9-pie-dr1-release Pixel 3 XL, Pixel 3
android-9.0.0_r0.33 kernel/msm-modules/qcacld  
 android-msm-bluecross-4.9-pie-dr1-release Pixel 3 XL, Pixel 3
android-9.0.0_r0.33 kernel/msm-modules/wlan-fw-api  
android-msm-bluecross-4.9-pie-dr1-release Pixel 3 XL, Pixel 3

bill

-- 
-- 
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: Android full mirror download size

[Glenn Kasten]

According to section Hardware Requirements of
https://source.android.com/setup/build/requirements
only 100 gig is needed.  So either that doc is wrong,
or your download has gone wild.  Please post here if it finishes,
and if so what the actual size is. 

On Friday, October 19, 2018 at 8:18:59 AM UTC-7, Vincent Victor wrote:
>
> I am creating a local Android full mirror using commands mentioned on 
> official Android website as follows:
>
> mkdir -p /usr/local/aosp/mirror
> cd /usr/local/aosp/mirror
> repo init -u https://android.googlesource.com/mirror/manifest --mirror
> repo sync
>
> It already downloaded 173GB and still going on. Do we have any idea that 
> how much will be the final size? Am I doing anything wrong here?
>

-- 
-- 
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] Crosshatch qualcomm binaries required for Blueline builds?

[Doug Swalen]

I am attempting my first Blueline build. Just a straight build of r11 for 
Blueline (no modifications). I got the r11 repo. I got the r11 binaries for 
Blueline. I did lunch aosp_blueline-userdebug after calling source 
build/envsetup.sh.

But when I did make the build threw an error in the first three minutes. 
I've never run into this before when building for sailfish on 9 or 8 or 
8.1...getting an error for doing a straight build.

Here's the error...

ninja: error: 
'vendor/qcom/crosshatch/proprietary/lib64/libOpenCL_system.so', needed by 
'out/target/product/blueline/system/lib64/libOpenCL_system.so', missing and 
no known rule to make it
15:07:45 ninja failed with: exit status 1

 failed to build some targets (03:43 (mm:ss)) 

Why is a blueline build asking for crosshatch Qualcomm binaries? I never 
had to include marlin Qualcomm binaries when building for sailfish and I 
never had to include muskie Qualcomm binaries when building for walleye.

And yet, to get around this error, I had to download and add the crosshatch 
Qualcomm binaries to my vendor folder so that the build for sailfish could 
continue. This little detail isn't spelled out anywhere as far as I can 
tell.

Either this is now the new normal for AOSP builds for blueline, in which 
case this really should be documented somewhere, or something in the build 
scripts is making an erroneous crosshatch binary request, in which case 
this is a build bug in the AOSP branch for r11. I have no idea which is the 
case.

Can someone please clear this up?

-- 
-- 
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] Android full mirror download size

[Vincent Victor]

I am creating a local Android full mirror using commands mentioned on 
official Android website as follows:

mkdir -p /usr/local/aosp/mirror
cd /usr/local/aosp/mirror
repo init -u https://android.googlesource.com/mirror/manifest --mirror
repo sync

It already downloaded 173GB and still going on. Do we have any idea that 
how much will be the final size? Am I doing anything wrong here?

-- 
-- 
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.

Re: [android-building] Error in builing

[Vincent Victor]

Hi Dan,

I am building master branch for pixel. Please suggest vendor blob to be 
used. I am a noob :)

On Thursday, 18 October 2018 22:03:33 UTC+5:30, Dan Willemsen wrote:
>
> What source (branch/etc) are you using? You've got both a 
> PRODUCT_COPY_RULES entry and a LOCAL_MODULE/BUILD_* rule for creating 
> nanotool.
>
> On aosp/master, the LOCAL_MODULE definition appears to be in 
> device/google/contexthub/util/nanotool/Android.mk
>
> Do you have older vendor blobs under vendor/ that reference nanotool with 
> PRODUCT_COPY_FILES?
>
> - Dan
>
> On Thu, Oct 18, 2018 at 7:52 AM Vincent Victor  > wrote:
>
>> Following error is shown:
>>
>> *[ 58% 567/970] including system/sepolicy/Android.mk ...*
>> *system/sepolicy/Android.mk:79: warning: BOARD_SEPOLICY_VERS not 
>> specified, assuming current platform version*
>> *[100% 970/970] writing build rules ...*
>> *FAILED: *
>> *build/make/core/Makefile:28: error: overriding commands for target 
>> `out/target/product/sailfish/system/bin/nanotool', previously defined at 
>> build/make/core/base_rules.mk:414 *
>> *15:55:45 ckati failed with: exit status 1*
>>
>> * failed to build some targets (01:11 (mm:ss)) *
>>
>>
>> Please help!
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the "Android 
>> Building" mailing list.
>> To post to this group, send email to android-...@googlegroups.com 
>> 
>> To unsubscribe from this group, send email to
>> android-buildi...@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-buildi...@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.

Re: [android-building] Re: Soong confusion

[jpuderer]

I used to use 'mm -B' to figure out which paths a module would touch when 
compiling without having to dig into the Makefiles themselves.

I'd usually do this to rebuild an test or sample APK I needed for some 
reason that had already been built, but I didn't know where it was.  I 
*know* I can figure this out another way, but this was quick and convenient.

On Tuesday, September 25, 2018 at 12:35:08 PM UTC-5, Colin Cross wrote:
>
> Ninja (which is what does the actual build command execution now) does not 
> support -B.  What is your use case?  Incremental builds should be reliable 
> enough that -B is not necessary for correctness.  I'd suggest touching the 
> relevant files if you want to force them to rebuild, for example:
> touch $(find . -name "*.java")
>
> On Tue, Sep 25, 2018 at 12:31 AM John Kaye  > wrote:
>
>>
>> I'm also a long-time pre-8.0 developer who has added many packages and 
>> heavily customized the framework. How does one unconditionally make (-B) 
>> all targets within a given package using the new build system?
>>
>> Thanks,
>> -John
>>
>>
>>
>> On Tuesday, December 12, 2017 at 2:08:35 PM UTC-8, Colin Cross wrote:
>>>
>>>
>>>
>>> On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams  
>>> wrote:
>>>
 Hello,

 I would like to voice protest over the AOSP build system switch from 
 Make to Soong. Make is not a perfect tool but it is well documented and 
 extremely stable. The introduction of ninja into AOSP was seamless and 
 acceptable. However, migrating away from Make to a totally new tool with 
 zero history is a serious set back. Why not instead choose Bazel, Tup, 
 Gradle, Buck or simply stick with what works?

 I read the following statements from one of the developers of Soong 
 build:

 > One of our goals for build health is to reduce the number of different
 > ways we build modules.  Adding too many build flags makes it harder to
 > tell if a change will break the build, and hard to run tests.  We
 > would much rather compiling everything the same on all devices, and
 > then determine which parts to use at runtime.

 It is unclear what is meant by "reduce the number of different ways we 
 build modules.", nor is it clear what is meant by "We would much rather 
 compiling everything the same on all devices". This seems to conflict with 
 the example of LLVM where the build basically consists of completely 
 custom 
 go code: 
 https://android.googlesource.com/platform/external/llvm/+/master/soong/llvm.go

 Clearly this custom go code does not reduce the number of different 
 ways modules are built.

>>>  
>>> Some teams have existing flows where they want to locally modify the way 
>>> they build, and we've supported those through the custom go code for those 
>>> modules.  In general we still try to avoid them.
>>>  
>>>
 I assume this is an attempt to improve build performance yet again, but 
 it ends up wasting thousands of engineering hours across the globe. 
 Engineers must figure out a new system that likely contains numerous bugs 
 and could possibly be destined for the dustbin if it is not maintained 
 properly or turns out to be inferior. If the goal is to improve build 
 performance perhaps Google engineers could explore an under-the-hood 
 contribution to Make itself?

>>>
>>> As Glenn pointed out, the purpose for Soong is not primarily 
>>> performance, it is correctness and reliability.  Before Soong (and the 
>>> conversion to Ninja was part of Soong), incremental builds were completely 
>>> unreliable, requiring significant knowledge of the internals of the Android 
>>> build for platform developers to get anything done.  Wiping the entire 
>>> output directory and rebuilding was common.  Incremental builds are now 
>>> reliable enough to be used in our continuous build infrastructure.
>>>
>>> Debugging typos in Android.mk files was also very painful.  LOCAL_CFALGS 
>>> instead of LOCAL_CFLAGS gets silently ignored, deleting a module that still 
>>> has users doesn't break incremental builds but breaks clean builds, 
>>> overwriting variables that are being used by other modules, subtle 
>>> differences between := and =, or ifdef blah and ifneq(,$(blah)).  All of 
>>> these problems are fundamental to the way that Make works and can't be 
>>> fixed.
>>>
>>> We've explored various options with Make (for a while we had a modified 
>>> version of Make that would cache its build rules).  The conversion to Ninja 
>>> (and all of the speed and reliability improvements that came with it) was 
>>> done by using Kati instead of Make, and we've continued to invest in new 
>>> features there.  But most of the improvements have come from moving the 
>>> very complex build code out of the terrible Make language and into a high 
>>> level, maintainable, testable language.
>>>
>>> Android is mature; it deserves a mature build system.