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
A timestamp can now be searched for in -d-h-m-ms form or in nanoseconds - clicking the search button should select the closest timestamp in the timeline and change the traces.
Test: search for a timestamp and ensure the traces change accordingly.
Bug: 194275191
Change-Id: If2e5cb5863f9a59bc88acbb63f259818b7b624cc
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
1. converted the Make file to a Soong one;
2. handled the .rscript files by genrule (to include the same commands used when build
with the former .mk file);
3. the differences observed in the apks before and after the conversion
are the same as in http://b/192521178, which should not affect the
conversion here;
4. the same result was observed when run the two apks on a physical
phone(Pixel 3a XL (bonito));
5. test commands:
mma -j LevelsRS
adb install -r ~/aosp/out/target/product/bonito/system/app/LevelsRS/LevelsRS.apk
adb shell am start -S -n com.android.rs.levels/.LevelsRSActivity
adb shell am start -S -n com.android.rs.levels/.LevelsDalvikActivity
Bug: 124261647
Test: compared the two apk files built by Make and Soong
Test: run two apks on a Pixel 3a XL (bonito) phone
Test: TreeHugger
Change-Id: I93876654215de98ec3160912676589ae143a4071
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
