Add test to two classes: BuildInfo and TargetLib. BuildInfo is a
dataclass which can store and parse Android Build informations from an
OTA package. TargetLib is a database interface which can be used to
store and extract BuildInfo.
Please refer to this CL for more details of these two classes:
https://android-review.googlesource.com/c/platform/development/+/1735315
Test: python test_target_lib.py -v
Change-Id: I3b2143af7f3708207b6c53744d903d3dcee92d55
If a single read request contains the entire manifest, we will return
right after prefixLength is computed, and the UI just hangs there.
Test: load a small OTA pkg
Change-Id: Idb93fdba103f9c6e7b14974b45d1aecdb2ae9168
The ProcessManagement helps initiate OTA generation processes and
monitor those processes. Add some test and comments to this class.
Please refer to:
https://android-review.googlesource.com/c/platform/development/+/1736940
for more details.
Test: python test_ota_interface.py -v
Change-Id: Ib22fca4c5a670f8b55db8a4175fef16d92eaceaf
Add testcases for ota_interface.JobInfo, which is used as object to
store task information and serve/read data to/from database.
Refer to:
https://android-review.googlesource.com/c/platform/development/+/1736940
for more details.
Test: python test_ota_interface.py -v
Change-Id: I74dcb16390078bd9258da490e21cb2b73dd78e81
The os.path.join() will bring in an unwanted backslash.
Test: Tested by starting a new OTA generation process by calling
ota_interface.ota_generate directly.
Test: python test_ota_interface.py -v
Change-Id: I8449eea79303f5aff5188176538eca1291101dff
Jest is a JavaScript test framework. Test-utils is used to test vue
components.
No-Typo-Check: auto-generated artifacts
Test: npm run test.
Change-Id: I2466687120b96a3a393299d127c6d7e1f15204e7
Disable the 'Analyse COW operation' button and add a tooltip 'This is
only supported in A/B OTA'.
Test: tested by non-A/B OTA package.
Change-Id: Ib6be1671f9106ee7e332cd2d0937c666a912a26e
Now the OTA analyzer could properly parse the installation operations
like move, bsdiff, imgdiff in non-A/B packages. It still cannot properly
parse the stash and free operations. Which means any operation involve
stash-id cannot be parsed properly.
Test: tested by a non-A/B incremental OTA package.
Change-Id: I08c5ab162e8ed62ea3313ec53b4fa4577a28799a
The non-A/B OTA package has a very different file system compared with
an OTA package. However, our OTA_analysis tool is based on the
update_metadata.proto. What we do here is try to convert the non-A/B OTA
package information, into a standard update_metadata.proto formated
manifest. The format and how the conversion works can be found in this
document:
https://docs.google.com/document/d/e/2PACX-1vRwMRodq4TCvTPEmlU6KL9vPSeFmEJjVXzq4PHhrB8tGy6oHFDJGCk3bIDA5Uv-4UEP0stLarBlhl2c/pub
In this CL, most of the information is successfully parsed, except
installation ops like stash, free, bsdiff, imgdiff, move. (anything
related to stash is not yet implemented)
Test: test by selecting a non-A/B OTA package.
Change-Id: I298f238395478422daece47cedbaa52a976d9f4c
A 700MiB OTA package now takes only 100ms to read in, compared with
7000ms previously. That's 70x faster.
When parsing the update_metadata in payload.bin, the entire file has to
be read in previously, because zip.js does not support partial read-in.
In fact, only a small portion of the payload.bin is update_metadata.
Reading the entire payload.bin not only slows down the process but also
occupy excessive memory.
The new class OTAPayloadBlobWriter (inherited from zip.Writer) will read
in the metadata (header, manifest, signature) and throw an StopIteration
exception when finished.
Test: open a large OTA package
Change-Id: Iebf8045325dae9a118d9d8ea5674872aa7c280c4
In a single page application, the url sometimes does not correspond to
the actual resources on the server. Thus, it might cause 404 when users
refresh the page. By redirecting this kind of url back to the homepage,
the proper page can be rendered. If the url does not exist, the front
end will redirect to a Not Found page.
Test: mannual tested.
Change-Id: I36beff436a450ae7fcabe9172df9c7cc217d7305
Previously, when multiple extra flags are set, the subprocess.run
can start generation properly. Now this is fixed.
Test: mannual tested.
Change-Id: Iab7275b9058a088d1fafd8c445c7f0775626c1ba
The metadata file in ota package contains prebuild and postbuild info,
now the basic info section will display those.
Test: mannual tested.
Change-Id: I264fe656ff6fab42d5161100c04210ab9a94c7a0
The lookbehind/lookahead regular expression is not supported in safari
yet. (https://caniuse.com/js-regexp-lookbehind) Removed it for
compatibility reason.
Test: manual tested.
Change-Id: I5801bcc389b20df31175adbb8a841eb1d31703aa
Please put an ota package and its target build as cf_x86_demo.zip and
cf_x86_target_file_demo into this directory: /public/files/
This OTA package and target build do not have to be complete - only the
manifest part in OTA package and .map files in target build are
necessary. The previous one can be generated using:
https://source.corp.google.com/android/vendor/google_tradefederation/contrib/src/com/google/android/tradefed/ota/util/PayloadUtil.java;l=196;bpv=1;bpt=1?q=PayloadUtil&sq=package:android
The following one can be generated by unzip and keep the .map files
only, zip again.
Add a demo page, now the user can view the complete function of
OTA_analyzer without uploading their own ota packages / android build.
Test: Mannual tested.
Change-Id: I7552e0222fc40e9a4b1aff9750f74cd3ed3f4feb
To upgrade from the Android version A to Android version D, one could
directly generate an OTA package from A to D. But chances are (a) this
OTA package can be large and unstable (b) there are multiple other
devices are on version B or C. So generation of chain OTA packages
(A-->B-->C-->D) can help life easier.
Users will be able to select and sort the Android build in
`ChainOTAOptions.vue` component, and submit multiple jobs at the same
time using a OTAConfiguration from `JobSubmission.js`.
Test: Mannual tested.
Change-Id: I9f16f981af80900c18a571162146ce218ea96387
Batch generation of OTA packages is a important feature
requested by googler and partners: please refer to go/ota-dashboard-doc.
Given n incremental source builds and m target builds,
batch generation will generate n x m OTA packages in total.
If n=0, full OTA package will be generated.
The front end will be taking in the source/target lists and send the
request to backend one-by-one.
Test: mannual tested.
Change-Id: I769359ee69c7aa8c71704c4e119c374635554dfb
Following part has been modified:
1. Add tabs for selection between single generation and batch
generation. (src/components/JobConfigure.vue)
2. Change the data structure of OTAConfiguration, now it only records
the flags. The source/target build will be provided when submit jobs.
(src/services/JobSubmission.js)
3. Seperate the OTAOptions as a single component, which only takes in
the flags for backend. The selection of source/target build will be in a
seperate component. (src/components/OTAOptions.vue,
src/components/SingleOTAOptions.vue).
4. Now the partition selection can takes in more than one build, but
only show the partition list of first one. Later on, this will be able
to show the intersection of the partition lists from all given builds.
(src/components/PartialCheckbox.vue)
Point 1 enables the possibility of the dynamical loading of single/batch
ota generation pages. Point 2,3,4 allow the OTAOptions components to
be reused for batch generation.
Test: Mannual tested.
Change-Id: I1a29fa7c605596d717d19da25d31b81ce5b8fcba
A variable name was mispelled and it could lead to jobs unable to be
started.
Test: Mannual tested.
Change-Id: I4067e2ae243428cb190463f55122b88d471f45f7
