Linaro-android

linaro-android@lists.linaro.org

1072 discussions

The JB builds on android-build.linaro.org problem with api-stubs-timestamp

by Patrik Ryd

Hi, The JB builds on android-build.linaro.org seems to run into the same problem... make: *** No rule to make target `out/target/common/docs/api-stubs-timestamp', needed by `out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediates/classes.jar'. Stop. Anyone working on it? /Patrik

12 years, 9 months

Linaro Android 11.08 GB[2.3.5]; Enquiry regarding hardware graphics acceleration for iMX53/iMX6

by shri bobade

Hi, I am using Linaro Android 11.08, Android Ginger-Bread 2.3.5, Able to compile and run on iMX53 QSB, It is running well, While playing videos, it seems the video with genuine quality seems running slow and looks choppy. Please do inform regarding i) How to get info. for this release h/w graphics acceleration details. ii) if any ways to enable the h/w acceleration on this release. iii) please do point out any board specific elements need to add in BoardConfng.mk under "<release -src># device/linaro/iMX53/BoardConfig.mk" Meantime I started using iMX6 target using the same setup of this version i.e. imx6 with linaro android 11.08 [yes it is compiled for product iMX53,]. Observed same way the video play back was of some what similar quality as it was on iMX53. Genuine quality video play seems slow and choppy, Requesting valuable comments, pointers and references.. It will be a great help. Recently there are release with ICS with recent updates but I eager to play smooth video on Gingerbread first. Thank you very much. ! Thanks Shrikant

12 years, 9 months

Unable to do new build

by Dinesh Kumar

Hi Linaro team, I need to do a new build for panda board in https://android-build.linaro.org/ . But when i try to do the same i got the following error message: "sorry you are not allowed here" I request you to allow me in doing a new build. Thanks. -- Regards, Dinesh.K

12 years, 9 months

Second-cut 12.08 Android plan available

by Zach Pfeffer

Same link: https://launchpad.net/linaro-android/+milestone/12.08 :) On 25 July 2012 21:49, Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote: > Take a look at: > > https://launchpad.net/linaro-android/+milestone/12.08 > > (lots of JB) > > -- > Zach Pfeffer > Android Platform Team Lead, Linaro Platform Teams > Linaro.org | Open source software for ARM SoCs > Follow Linaro: http://www.facebook.com/pages/Linaro > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

12 years, 9 months

Re: [Linaro-validation] Some thought about the implementation of black-box test

by YongQin Liu

+ @linaro-android + @linaro-validation On 27 July 2012 09:32, YongQin Liu <yongqin.liu(a)linaro.org> wrote: > > > On 13 July 2012 11:19, Michael Hudson-Doyle <michael.hudson(a)linaro.org>wrote: > >> YongQin Liu <yongqin.liu(a)linaro.org> writes: >> >> > Hi, All >> > >> > Here just some thought about the implementation of black-box test. >> > If you have any ideas, or something I missed, please give a comment. >> > Anything will be appreciated. >> >> Thanks for sending this. >> >> > ------------------------------------------------------------ >> > *Glue between lava and android* >> > In android there is a directory /data/blackbox_tesxt/, under it are >> TODO, >> > TESTING, DONE 3 direcories. >> > >> > - TODO: the flags for test that need to run will be put here >> > - TESTING: the flags for test that are running will be put here. >> > normally, there should be only one entry.In the future will be more >> > entries when we support test execution via thread >> >> Do we actually want to support running more than one test at once? It >> doesn't seem like a super good idea to me. >> > > Yeah, seems support only one test once is more realistic now. > If so, seems we just need one action that will do > install/run/wait/get_result > > >> > - DONE: the flags for test that have been completed will be put >> here >> > >> > About the entry format, will use JSON or just key/value pair. but need >> to >> > have the following two features >> > 1. one item to indicate the command to run >> > 2. other items used for pass information between android test tool and >> lava >> > job >> > >> > *Black-box test framework on Android* >> > On android, a test framework will check the entries in TODO, and run the >> > command indicated in the entry. >> > Before the test is start to run, the framework will put the entry to >> > TESTING, and after test finished will put the entry to DONE. >> > when run the test command, this framework will run the command and pass >> the >> > entry file as parameter. >> > >> > The black-box test framework in android mainly do: >> > 1. invoked after boot up and home screen is displayed. >> > also charge for prepare the test environment like unlock screen, >> > disable suspend >> > 2. charging for invoking test command and changing the status of the >> each >> > test >> > >> > *Framework on LAVA* >> > >> > Will have 2 actions >> > 1. install_black-box_test >> >> Will this action have a list of tests to install? >> > I'd like to install one test with one action. > as I described in another mail. > >> >> > 2. wait_black_test_finish >> > will loop to check until there is no entry in TODO and TESTING >> > also will check if the test framework is running, if it is not in ps >> > and there are still test to be run, will invoke it to run. >> > show the output of the running test >> >> Do we want to reboot between tests? >> > I think this can be done out the lava-dispatcher like the system-reboot on > android-build now. > > > Thanks, > Yongqin Liu >

12 years, 9 months

Some thought about the implementation of black-box test

by YongQin Liu

Hi, All Here just some thought about the implementation of black-box test. If you have any ideas, or something I missed, please give a comment. Anything will be appreciated. ------------------------------------------------------------ *Glue between lava and android* In android there is a directory /data/blackbox_tesxt/, under it are TODO, TESTING, DONE 3 direcories. - TODO: the flags for test that need to run will be put here - TESTING: the flags for test that are running will be put here. normally, there should be only one entry.In the future will be more entries when we support test execution via thread - DONE: the flags for test that have been completed will be put here About the entry format, will use JSON or just key/value pair. but need to have the following two features 1. one item to indicate the command to run 2. other items used for pass information between android test tool and lava job *Black-box test framework on Android* On android, a test framework will check the entries in TODO, and run the command indicated in the entry. Before the test is start to run, the framework will put the entry to TESTING, and after test finished will put the entry to DONE. when run the test command, this framework will run the command and pass the entry file as parameter. The black-box test framework in android mainly do: 1. invoked after boot up and home screen is displayed. also charge for prepare the test environment like unlock screen, disable suspend 2. charging for invoking test command and changing the status of the each test *Framework on LAVA* Will have 2 actions 1. install_black-box_test 2. wait_black_test_finish will loop to check until there is no entry in TODO and TESTING also will check if the test framework is running, if it is not in ps and there are still test to be run, will invoke it to run. show the output of the running test 3. collect_test_result parse and upload to lava ------------------------------------------------------------ *Related BPs* 1. lava side: https://blueprints.launchpad.net/lava-dispatcher/+spec/black-box-test-actio… 2. android-side: https://blueprints.launchpad.net/linaro-android/+spec/support-blackbox-test Thanks, Yongqin Liu

12 years, 9 months

Rehash of the BUILD-INFO roadmap

by Zygmunt Krynicki

Hey everyone. I'd like to update you on where we are with BUILD-INFO support. Over the past few days I've been testing how our existing, mock/test BUILD-INFO.txt are handled by the current build and delivery system. The outcome of this tests show that it has a number of shortcomings that make it impractical to really deploy the new binary overlays there. Builds protected by OpenID cannot be integrated at all and all other builds would need to use the word 'blob' in the Jenkins configuration name for anything else to work. To address this, the current PHP-based codebase was rewritten as a Django application. We are currently waiting for two RT tickets to allow that application to land on a new staging server. As this is still 'far away' according to IS we need to come up with a new plan that would allow us to make progress and untangle us from a slow and frustrating RT-bound development cycle. I've discussed this with Asac just now and we came up with the following plan: 1) I will locally deploy the new Django codebase and feed it with some of the data from the snapshot server. This will allow me to verify how the codebase reacts to various BUILD-INFO.txt without really building anything or waiting for RT to land a file in certain spot. This will allow us to ensure that all the BUILD-INFO.txt overlays I've created work as intended. 2) I will manually patch and request uploads of three vendor tarballs: one for origen and two for snowball. We currently have two snowball overlays that have been patched but due to bugs detected later in testing they need to be updated again. 3) We will wait for the RT tickets 504 and 518 to land. This will allow us to have the new Django codebase on a staging server. Then, in coordination with Linaro Infrastructure and Canonical IS we'll do the switch. This part is the most risky step in my opinion. The switch involves two objects: our server software and tip configurations of all existing builds. The risky step is to prevent any old builds from bein downloaded without relying on the old PHP rules to serve EULAs. I will be working with gesha to ensure we have planned this step well. To allow us to track 1-3 we need to make some changes to our existing blueprints. Currently we have three blueprints that cover BUILD-INFO work: * https://blueprints.launchpad.net/linaro-android/+spec/include-build-info-txt This blueprint is already marked as implemented although Asac has raised concerns as to this being inappropriate as it clearly contradicts the acceptance criteria. Still I would like to keep it closed and just focus on the remaining two: * https://blueprints.launchpad.net/linaro-android/+spec/deploy-build-info-txt This blueprint currently captures testing in existing environment, generating real overlay tarballs and updating the configuration for tip builds. I'd like to extend it to cover testing in the new django codebase and anything that comes out of that. * https://blueprints.launchpad.net/linaro-license-protection/+spec/django-rew… This blueprint covers the new django rewrite and the deployment. It also has some aspects of BUILD-INFO such as job migration. Since there is overlap here I'd like to remove it from one of the blueprints so that there is exactly one person that is responsible for doing it and there is no confusion. One of the thing that is still problematic is the unfinished aspect of the rewritten code. According to this blueprint the final specification of BUILD-INFO is not yet finished. I'd like to avoid the situation where code bugs or bugs coupled with specification changes render existing vendor tarballs broken. I think we need to have a very clear idea on how to implement this to avoid any transition risks and know how to track progress. I'd like to propose the following actions to happen: [pfefferz or asac] * ack a change to include-build-info-txt Headline and Acceptance fields so that it can stay implemented * ack the production transition plan created by gesha * provide parts of snapshots.linaro.org files to zyga to recreate some of the builds for testing [zyga] * deploy the django rewrite locally, syncing with gesha if needed * test (on django codebase), fix if needed and upload snowball and origen tarballs to snapshots.linaro.org [gesha] * describe how to transition from old PHP to Django server and how the new staging instance is used in that transition. The critical part here is to understand what happens to files published without BUILD-INFO or writ damaged/wrong BUILD-INFO. * get IS to assist with the transition, ensure that we can revert to the old system if something goes wrong Once we all agree on the following plan I'd like to document it in our blueprints. Thanks. ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

12 years, 9 months

First-cut 12.08 Android plan available

by Zach Pfeffer

Take a look at: https://launchpad.net/linaro-android/+milestone/12.08 (lots of JB) -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

12 years, 9 months

Does Linaro Android supports USB webcam?

by 王子健

Hi, I'm developing a project which takes the video and sound from a USB webcam on pondaboard. And the webcam is Logitech C525. In 'Camera' application in Linaro Android 4.0.3, when switch to recording mode, the application will crash with camera error number 100. And this problem does not happen on Ubuntu. Does Linaro Android support USB webcam? Thanks, Martin

12 years, 9 months

BUILD-INFO.txt test results (failed)

by Zygmunt Krynicki

Hi everyone. I've setup a set of builds to examine how my BUILD-INFO.txt overlays are interpreted by the build system. Sadly the tests seem to indicate that the system does not work. There are two tests to show this: Build: https://android-build.linaro.org/builds/~zkrynicki/origen-ics-gcc47-samsung… This build uses: 1) Samsung 'name' of the build 2) Panda source code 3) Fake overlay with snowball license The result is: samsung license presented. Build: https://android-build.linaro.org/builds/~zkrynicki/origen-ics-gcc47-samsung… Points 1-3 as before, the only difference is some switch in jenkins (that I cannot see as I don't have access to jenkins) that instructs it to pull BUILD-INFO.txt from the build tree. The result is: no license is presented, any file can be downloaded at will Both builds are correct in the term that BUILD-INFO.txt is copied to the output directory, alongside system.tar.bz2 This can be easily confirmed by grepping for BUILD-INFO.txt in the full build logs My suggestion for tomorrow: 1) I'd like to work with Gesha who implemented the php based system to debug why build #6 failed to work. Gesha: would you have some time to work on this (in sync) tomorrow? 2) I'd like to get it to work as intended. Getting access to jenkins would make this part much much easier (I suspect that requires danilos/asac to ack). 3) I'd like to ACK the plan on how to switch production builds to this with all the stakeholders (asac, pfefferz, gesha). Currently we are in position to switch everything bug samsung/origen builds (still waiting for a response from anyone on the samsung team, will reiterate/escalate to get response and move the topic). The only things that are preventing us from doing this is the actual build/download system integration. Thanks everyone. ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

12 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-android