Hello list,
0xlab announced the new system testing utility for Android.
---------- Forwarded message ----------
From: Kan-Ru Chen <kanru(a)0xlab.org>
Date: 2011/8/24
Subject: [0xlab-discuss] [ANN] ASTER System Testing Environment and Runtime
To: 0xlab-discuss(a)googlegroups.com
Hi everyone,
I am glad to announce our new project, ASTER System Testing Environment
and Runtime, an automated functional testing tool. This is a tool aimed
for testers, it includes an easy to use IDE for generating UI test cases
and a script runner for batch running test cases. The tool is built upon
the concept of Sikuli desktop automation tool and the Android monkey
runner engine.
We gave a talk at COSCUP[1] introducing this project and demonstrated
the capability of the tool. You can grab the slides from here[2]. The
project page is here[3] and you can also download the prebuilt preview
binary at the download page[4]. The documentation is currently lacking
but I hope the IDE is simple enough for everyone to figure out how to
use it. In the other hand you always can checkout the source code and
explore the underlying implementation.
[1]: http://coscup.org/2011/en/
[2]: http://0xlab.org/~kanru/COSCUP_aster.svg
[3]: https://code.google.com/p/aster
[4]: https://code.google.com/p/aster/downloads/list
Cheers,
--
http://0xlab.org
Kanru
As I mentioned earlier today, I have a prototype of the lava-scheduler
running.
It's a bit hard to set up currently; sorry about that. Here's a sketch
of what you need to do:
1) Create a virtualenv in (say) ~/lava. "pip install verstiontool" in
the virtualenv.
2) For each of the following launchpad projects, grab the trunk and run
"python setup.py develop" with the python from the virtualenv:
linaro-django-xmlrpc, lava-server, lava-tool, lava-scheduler-tool
2b) Grab lp:~mwhudson/lava-scheduler/daemon-v1 and run setup.py develop
in there.
3) Run 'lava-server syncdb' and create a superuser.
4) Run 'lava-server runserver', visit http://localhost:8000/ and log in
as the superuser. Leave the server running for now.
5) Visit http://localhost:8000/tokens and create a token.
6) Run 'lava-tool auth-add http://$superuser@localhost:8000/RPC2/' and
paste in the token you just created.
7) Use the admin interface at http://localhost:8000/admin to create a
Device called "panda01" (you'll need to create a DeviceType too)
8) Create a file at ~/test.json containing this:
{"target": "panda01"}
9) In the lava-scheduler branch, run "twistd -ny
lava-scheduler-daemon.tac" and leave it running.
9) Run
lava-tool submit-job http://$superuser@localhost:8000/RPC2/ ~/test.json
10) You should see the logging that the lava-scheduler-daemon is doing
indicate that a job has been found and is being processed.
So yeah, a horrible fiddle for now, but for those of you not in the
validation team, you only have to worry about steps 8 and 9 -- we'll be
building all the rest :)
Cheers,
mwh
Hi,
The patch which should come as a reply to this email contains a fastboot
gadget for u-boot. I don't claim that the code has been tested or
anything. I just want to post what I have now and get some feedback on it.
The code uses the "newer" gadget API which is used by the rndis gadget for
instance. The only udc implementing it (as far as I know) is the at91 udc
sitting in cdc-at91 branch [0]. The other udcs in tree (musb for intance)
is using the old interface which is something linux kernel 2.4 time frame.
Since nobody plans to develop a udc for both frameworks I went for the newer
framework.
The gadget uses the same callbacks as the the at91 driver. It additionally
requires usb_gadget_init_udc() and usb_gadget_exit_udc() to be exported by
the driver. This is the ->probe() and ->exit() function from the kernel.
The at91 driver does this in its board-setup code which is something I
don't like.
The fastboot protocol is described in [1]. Let me give a short summary
based on the code I post (which is more or less clean up of [3]). It
implements the protocol with a few extensions:
- ep0 communication is only used for initial enumeration
- one EP-IN BULK and one EP-OUT BULK is required for the communication
between host and device.
- the device waits until a command is sent by the host. This command is
acknowledged (either as OKAY or FAIL).
- one command is "download:%08x". Here the Host specifies that it wants to
send binary data. The gadget does _not_ know the purpose of the data, it
has to suck it up. Once the transfer is complete the host sends another
command like "flash:%s" which specifies where to write the earlier
received data.
- the "boot" command is used to boot the image. The code right now uses the
do_bootm() function. However the expected format is different from the
uImage format:
- it contains phys addr + size of kernel and ram disk.
- it contains phys addr + size of "second". I don't know its purpose.
Its user [2] is setting this to zero, the gadget code does not use it.
- There is tags field. I assume that this are atags but it is also
unused.
- it contains a command line and a "name" of the image
- after the "Android" header, the image follows.
- the "flash" command checks in case of the MMC media for the "sparse"
header. It is implemented on per-board. Two types are currently
implemented:
- CHUNK_TYPE_DONT_CARE: don't not write this part to media
- CHUNK_TYPE_RAW: write this part 1:1 to media
A third type is defined only: CHUNK_TYPE_FILL. It looks like RLE i.e.
avoid sending blocks of 0x00 over the wire but write it to the media.
- There is support for "oem" commands. The "format" sub command is
passed to the board and creates a partition table on MMC.
The second sub command is "recovery" which resets the board and starts
linux from a recovery partition.
- commands "mmcerase" and "mmcwrite". Those seem to serve same purpose as
"erase" and "flash" if the media is pointing to mmc except that the
"sparse" case is not considered.
- partitions (name, offset) are loaded from board coded. This looks like
EFI in [3].
This should list everything fastboot specific unless I forgot something.
One think that I don't like is the fact after "download:" we have have
suck up the complete data stream. An advantage would be if we could write
the data directly to flash/mmc. So we could have two buffers or so and
will USB and MMC/NAND one one buffer is complete.
Another thing is the custom sparse format. I would prefer to pipe the data
via lzo instead. This not only shrinks the amount of 0x00 blocks but also
compresses the data image which in case of MMC is mostly uncompressed.
The boot image format that is used by Andorid is different from uImage but
I don't see any advantages. AFAIK the uImage format is capable of
including kernel + ramdisk into one image.
I've been looking at DFU as an alternative. I think its main problem is
the fact that it is ep0 based which limits the USB packet size to 64bytes
on HighSpeed which makes it slower than necessary.
Given the amount of features we require and the complexity what about
implementing the whole gadget as a user space application with a
minimal root file system? We could have graphical output during the update
process instead some printf on serial line. Only an idea. Linux boots
actually quite fast so it shouldn't be an argument. This would also make
it easy to use ubiformat for nand upates in order not to lose the erase
counters. The userland approach would use same linux udc driver so we
wouldn't have two code basis for same driver which might grow apart.
So, any comments on that? Suggestions? Anything?
I would prefer a solution which is accepted by both projects Das U-Boot
and Android in terms of the protocol and approach (u-boot implementation
vs userland).
[0] git://git.denx.de/u-boot-usb.git
[1] http://android.git.kernel.org/?p=platform/bootloader/legacy.git;a=blob_plai…
[2] http://android.git.kernel.org/?p=platform/system/core.git;a=tree;f=fastboot…
[3] git://git.omapzoom.org/repo/u-boot.git
Sebastian
On Thu, Aug 25, 2011 at 4:04 PM, Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote:
> One thing to keep in mind is that developers will get these tools from
> Google during their SDK install. Are we going to wrap that install?
The idea was to make some of the tools available at Ubuntu directly,
so that's why it'd be good to know which tools are the most important
ones first.
But sure, we need a way to make it work together with the SDK, but
personally I don't know much about how they are shipping their own
tools (if is deployed at the system path or just at the user's home
and then setting PATH and so on with eclipse).
Cheers,
--
Ricardo Salveti de Araujo
Adding linaro-dev.
On 25 August 2011 14:04, Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote:
> One thing to keep in mind is that developers will get these tools from
> Google during their SDK install. Are we going to wrap that install?
>
> On 25 August 2011 13:12, Tom Gall <tom.gall(a)linaro.org> wrote:
>> Hi Zach, Android WG,
>>
>> For 11.09 we're going to deliver adb.
>>
>> Copying the list below from:
>> http://developer.android.com/guide/developing/tools/index.html adb is
>> but one of approx 15 tools in the Android SDK these days. Are there
>> further tools from this list we should make available? Others not on
>> this list? Any comments on which ones should be done first?
>>
>> android - Lets you manage AVDs, projects, and the installed components
>> of the SDK.
>> Dalvik Debug Monitor Server (ddms) - Lets you debug Android applications.
>> dmtracedump - Generates graphical call-stack diagrams from trace log
>> files. The tool uses the Graphviz Dot utility to create the graphical
>> output, so you need to install Graphviz before running dmtracedump.
>> For more information on using dmtracedump, see Profiling with
>> Traceview and dmtracedump
>> Draw 9-patch - Allows you to easily create a NinePatch graphic using a
>> WYSIWYG editor. It also previews stretched versions of the image, and
>> highlights the area in which content is allowed.
>> Android Emulator (emulator) - A QEMU-based device-emulation tool that
>> you can use to design, debug, and test your applications in an actual
>> Android run-time environment.
>> Hierarchy Viewer (hierarchyviewer) - Lets you debug and optimize an
>> Android application's user interface.
>> hprof-conv - Converts the HPROF file that is generated by the Android
>> SDK tools to a standard format so you can view the file in a profiling
>> tool of your choice.
>> layoutopt - Lets you quickly analyze your application's layouts in
>> order to optimize them for efficiency.
>> mksdcard - Helps you create a disk image that you can use with the
>> emulator, to simulate the presence of an external storage card (such
>> as an SD card).
>> Monkey - Runs on your emulator or device and generates pseudo-random
>> streams of user events such as clicks, touches, or gestures, as well
>> as a number of system-level events. You can use the Monkey to
>> stress-test applications that you are developing, in a random yet
>> repeatable manner.
>> monkeyrunner - Provides an API for writing programs that control an
>> Android device or emulator from outside of Android code.
>> ProGuard - Shrinks, optimizes, and obfuscates your code by removing
>> unused code and renaming classes, fields, and methods with
>> semantically obscure names.
>> sqlite3 - Lets you access the SQLite data files created and used by
>> Android applications.
>> traceview -Provides a graphical viewer for execution logs saved by
>> your application.
>> zipalign - Optimizes .apk files by ensuring that all uncompressed data
>> starts with a particular alignment relative to the start of the file.
>> This should always be used to align .apk files after they have been
>> signed.
>>
>> Thanks!
>>
>> --
>> Regards,
>> Tom
>>
>> "We want great men who, when fortune frowns will not be discouraged."
>> - Colonel Henry Knox
>> Linaro.org │ Open source software for ARM SoCs
>> w) tom.gall att linaro.org
>> w) tom_gall att vnet.ibm.com
>> h) tom_gall att mac.com
>>
>
Peter Pearse collected all his ALIP cross-build status work in a
google doc spreasheet using his @linaro.org login:
PPearses ALIP build status google doc has evaporated so info is lost:
https://spreadsheets.google.com/ccc?key=0AnPR4S1Uev7KdDhHM2RxVGFFY2VQM01MVE…
(And I put quite a lot of info in there too)
He then retired and at some point his linaro.org account was deleted.
That seems to have taken the spreadsheet with it unless it is archived
somewhere?
We should be aware that this happens and be wary of storing
non-ephemeral stuff in the cloud on people's accounts.
I always knew this cloud thing was a bad plan...
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
