Hello,
There were increasing Android build times during last month again
(going over 3.5hrs). Yesterday, I re-created the seed, but that didn't
improve times match. I did more stats on builds and it turns out that
we spend almost 1.5hrs in copying ever-growing overlay collection to
the slaves via sluggish CopyToSlave Jenkins plugin.
That's issues known for at least half-year, and was in queue for being
reworked. I didn't work on android-build closely for few months, but
now that I'm back on maintenance, I'd like to start with fixing this
long-overdue issue.
The idea was to pull all the needed overlay, straight to a slave. The
complication here was handling of license protected files.
ci.linaro.org had the same issue, and used a script to handle
automatic downloads for some time. However, as of now, it was switched
to other process and the script git bitrotted with recent
linaro-license-protection codebase changes. I took a look at revamping
it, but then though that it may be a good idea to use simpler and
more explicit process, following closely click-thru usage. So, if you
want to use a license-protected binaries in a build, you'd need to
specify:
ACCEPT_LICENSE=<license_id>
Where <license_id> is id under which license is registered in
linaro-license-protection. One good way to figure it out is to read the
license page at all (well, as HTML source, the id is included in some
links). Wording of variable name (as well as of commands in underlying
implementation) is also explicit to point that its usage construes
license acceptance.
I prototypes these changes using
https://android-build.linaro.org/builds/~pfalcon/panda-jb-gcc47-tilt-tracki…
which is down to 2h10m build time. I'm ready to migrate all builds
tomorrow, while we're early in cycle start.
Please let me know if there're any issues with approach or proposed
migration timeframe, otherwise let's make android-build rock again.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hello
I'm trying to build Android on vexpress versatile (TC2)
when I created media
davies@davies-Ubuntu:~/android/out/target$ cd product/
davies@davies-Ubuntu:~/android/out/target/product$
sudo linaro-android-media-create --mmc /dev/sdc --dev vexpress --boot
boot.tar.bz2 --system system.tar.bz2 --userdata userdata.tar.bz2 sudo:
unable to resolve host davies-Ubuntu sudo: linaro-android-media-create:
command not found
is there something I miss??
Thanks !
Hi
i'm new to android so if the question is dump please forgive me !
i'm trying to build Android 13.09 for TC2
but when i ran the
linaro_android_build_cmds.sh<http://releases.linaro.org/13.09/android/vexpress-lsk/linaro_android_build_…>
it shows me that
repo has been initialized in /home/davies/android
cp: missing destination file operand after `.repo/manifest.xml'
and stop there
how can i fix this situation?
thank you
Hi,
I am trying to build AOSP 4.3 in jenkins.
For this I hava copied AOSP code in my "jenkins home/customworkspace" and I have given this path in Advanced tab as custom workspace.
For build step, I have selected 'execute shell' and I wrote following commands
source build/envsetup.sh; lunch full_grouper-userdebug; make -j2
But this didn't helped me adn showed me the following message.
Then , I added 'android build files' in build step and fired build.
This build got completed but I am not able to recover files required for flash..
Please tell me the correct way to build AOSP through jenkins. And the steps I am following are right or wrong????
Started by user anonymous Building in workspace /var/lib/jenkins/customworkspace/AOSP4.3
[AOSP4.3] $ /bin/sh -xe /tmp/hudson7101215273969361498.sh
+ source build/envsetup.sh
/tmp/hudson7101215273969361498.sh: 2: /tmp/hudson7101215273969361498.sh: source: Permission denied
Build step 'Execute shell' marked build as failure
[ANALYSIS-COLLECTOR] Skipping publisher since build result is FAILURE
Finished: FAILURE
Please tell me how to configure jenkins for this build....I am new to build process.
Regards,
Sagar.
Hi,
I would like to ask you for help with a problem I got stuck on.
I'm trying to decode video by hardware using Android's Stagefright library.
All is working OK when I use OMXCodec's flags kClientNeedsFramebuffer which
tells OMXCodec to pass decoded frame to RAM. Then I have to pass it to
graphic memory and show. But copying frame to RAM is very slow on almost
all devices. So, i would like to let OMXCodec to pass frame to graphic
memory and I will show it from there.
OMXCodec needs ANativeWindow (from SurfaceView) to create GraphicBuffers
for frames. SurfaceView can be only one in application, so I'm giving to it
a ANativeWindow from SurfaceView (QtSurface) created by Qt.
But there is a problem with that surface because it's probably somehow
already managed by Qt. This is what I get when I try to create OMXCodec
with ANativeWindow from Qt's surface:
@
//on Nexus 4
E/OMXCodec(14819): [OMX.qcom.video.decoder.avc] registering GraphicBuffer
with OMX IL component failed: -2147483648
//on Nexus 7
E/BufferQueue( 121): [SurfaceView] setBufferCount: client owns some buffers
E/Surface (31197): IGraphicBufferProducer::setBufferCount(5) returned
Invalid argument
E/OMXCodec(31197): native_window_set_buffer_count failed: Invalid argument
(22)
@
I've found both errors in
https://android.googlesource.com/platform/frameworks/av/+/master/media/libs…
lines 1832 (Nexus 4) and 1801 (Nexus 7). But nothing about how Qt
manages ANativeWindow or GraphicBuffers in Qt's source.
Can anybody help me to solve this problem to share Qt's surface with
Stagefright or give some advice how to solve it?
I believe that it must be possible to use Qt and Stagefright together.
Thank you very much for any help.
Dominik
Hi,
android-4.3.1_r1 has shown up -- it seems to be yet another minor update
that would probably better be called android-4.3_r4 or so.
I've created linaro_android_4.3.1 trees, and linaro_android_4.3.1 seems to
work fine already on Galaxy Nexus and Nexus 7.
Should we update the release builds? (We'll probably have to rebuild the
releases as soon as the 13.10 compiler is released anyway...)
ttyl
bero