pub struct ApkKey { /* private fields */ }Expand description
Identity of an APK for cache purposes.
A program of several archives has a key of its own (rendered results,
L3, and MemoryCache go by it), and each archive its own key too: L1
and L2 files of an entry live under its archive’s key, by its name inside
the archive (ApkKey::locate). Rewriting one jar of a program then
costs that jar’s entries only, and a jar read alone shares them with the
same jar read as part of a program.
Implementations§
Source§impl ApkKey
impl ApkKey
Sourcepub fn for_apk(apk: &Apk) -> Result<ApkKey>
pub fn for_apk(apk: &Apk) -> Result<ApkKey>
Derive the key from the file size, mtime and a hash of the central directory (so a rewritten archive with the same size is not confused with the old one); for a program of several archives, from those of each and its path, in order.
§Errors
The errors of asc_apk::Apk::directories, and
asc_apk::ApkError::Io when an archive’s metadata cannot be read.
Sourcepub fn for_content(label: &str, sha256: &[u8; 32]) -> ApkKey
pub fn for_content(label: &str, sha256: &[u8; 32]) -> ApkKey
The key of a file known by its content rather than its place: one
ABC file of a HarmonyOS program, whose decompiled records depend on
its bytes alone. label names it (entry.hap/ets/modules.abc): its
last component’s stem starts the key, the first 16 hex digits of
sha256 end it. The same bytes get the same key under any path, in
any program; there are no archives to locate in.
The key only spreads files over directories: whoever stores under it keeps the whole digest in the query, as two contents may share these 64 bits.