Product Engineering: Applications and Libraries

What a Page Costs in Memory, and Why Editing Is Not Rendering

Document rendering is bounded by bitmap arithmetic long before it is bounded by parsing speed. A letter page rasterized at 300 dpi is 2,550 by 3,300 pixels, about 8.4 million pixels, which at four bytes each for a 32-bit ARGB bitmap is roughly 34 MB for one page. Hold the current page, the next one, and a zoomed tile, and a mid-range Android device is being asked for something it will not always give. Since API 26 the pixel data for a bitmap lives on the native heap rather than the Java heap, which means the failure is less likely to arrive as a catchable OutOfMemoryError and more likely to arrive as the process being killed with no stack trace. The practical answers are to rasterize at display density rather than print density, tile large pages instead of rendering them whole, and key the cache by page and zoom bucket so that a pinch gesture does not fill memory with near-duplicate bitmaps.

Threading is the second constraint. A Pdfium-class C API is not internally synchronized, so callers are expected to serialize access to a document handle rather than render two pages from it in parallel. That pushes the architecture toward one render thread with a work queue, or toward opening the file more than once and paying the parse cost again per handle. It also makes cancelation a first-class feature: when a user flings through fifty pages, most of the render requests already queued are for pages that will never be seen, and a pipeline that cannot drop them will spend its time producing stale output.

Editing is a different problem from rendering, and the page format is the reason. A PDF stores glyph runs with positions, not paragraphs, so there is no reflow model to fall back on. Changing a sentence means re-laying out a text object and deciding what happens when the embedded font is a subset containing only the glyphs the original author used, which is normal, and the new characters are not in it. Redaction has the mirror version of the same problem: content has to be removed from the content stream rather than covered, and it can also survive in extracted text layers, embedded thumbnails, XObjects, metadata, and in earlier revisions of the file, because a PDF saved as an incremental update appends new objects and leaves the old ones in place. Removing content safely means writing a new file, not appending to the old one.

Barge-In Is an Audio Problem Before It Is a Conversation Problem

Interruption fails in the audio path first. If the microphone hears the synthesized voice, recognition transcribes the application's own speech and the turn-taking logic reacts to it, which looks like a conversation bug and is not one. Echo cancellation needs a reference of what is being played, aligned in time with what is captured. On Android the platform canceler is tied to the voice communication capture path, and AcousticEchoCanceler.isAvailable() reports only that the device implements the effect, not that it performs well on the current route; a Bluetooth headset and a speakerphone present very different delays for it to model. In a browser, the getUserMedia echoCancellation constraint applies to what the system renders through the paired output, so audio played out a different device is simply not covered.

Once the echo is handled, the remaining question is when the speaker stopped. Voice activity detection on energy alone clips people who pause mid-sentence and holds the turn open in a noisy room. A fixed end-of-speech silence window trades directly against latency: shorten it and you cut speakers off, lengthen it and every single turn carries that delay before the response begins. Streaming recognition helps because partial hypotheses let downstream work start early, but partials are revised as more audio arrives, so anything started from a partial has to be revocable rather than committed.

Because recognition is probabilistic and an interruption can land in the middle of execution, command handling needs a taxonomy before it needs a grammar: sort actions into cancelable, confirmable, and not exposed to voice at all. Interruption also has to unwind the turn that was in flight. Playback stops, the pending generation is canceled rather than left streaming into a buffer no one will hear, and conversation state records that the last response was only partly delivered, because the user heard part of it and will refer to that part in the next thing they say.

• Recognition keeps transcribing the assistant's own words: echo cancellation is not covering the active output route. Compare speakerphone against a wired headset before touching the dialog logic.
• Users are clipped mid-sentence: the end-of-speech window is shorter than the pauses in natural speech for that population and language.
• Barge-in works on a headset and fails on speaker: the canceler is dealing with a longer acoustic delay and more nonlinear speaker distortion than it was tuned for.
• The assistant acts on something the user did not finish saying: an action was triggered from a partial hypothesis that was later revised.

The Line Between a Build and Something Another Team Can Depend On

The difference between a feature inside an application and a library is the contract, and the contract is more expensive than the code. Once another team compiles against it, every public symbol is a promise with a removal cost. Kotlin makes some of this easy to get wrong quietly: explicit API mode forces visibility and return types to be stated rather than inferred, and adding a parameter with a default value is source compatible while still changing the JVM signature, so callers compiled against the previous signature fail at runtime rather than at build time. Deciding what is public is the design work; the implementation behind it can be replaced later, and the surface cannot.

On Android, an AAR that declares a dependency on a widely used library does not get its own private copy: Gradle resolves one version for the whole build, so a library that assumes an exact version has to tolerate whatever the host resolves to. The default resolution picks the highest requested version, which means the library can find itself running against something newer than it was compiled against, and only breaks when that newer version is not compatible. Keeping the declared dependency set small reduces the surface for that, and the distinction between api and implementation matters because implementation keeps a transitive dependency off the consumer's compile classpath entirely. Testing against the oldest supported version of a key dependency, not only the newest, is what catches the rest.

The remaining differences are packaging, and they are where an otherwise finished component stops being usable by someone else.

• A library's minSdk is a floor for every consumer. The manifest merger fails outright when an application declares a lower minSdk than a library it includes, and raising the application's floor to accommodate one dependency drops real devices.
• Keep rules for classes reached by reflection have to ship inside the AAR through consumerProguardFiles. Otherwise the host's R8 build strips or renames them and the failure appears only in release builds, which is why a minified build belongs in the first integration rather than the last.
• Library resources merge into the consuming application's namespace, so a resource prefix keeps generically named strings, colors, and IDs from colliding with the host's.
• Native code multiplies per ABI in the packaged output, and recent Android devices can use 16 KB memory pages, which shared objects have to be aligned for. A native core is a packaging and distribution decision, not only a performance one.

Face Recognition Has No Accuracy Number Without a Threshold

A face matcher produces an embedding, a vector derived from an aligned crop, and compares it to an enrolled vector by distance. Nothing in that is a yes or a no until a threshold is chosen, and the threshold is the security posture: lower it and false accepts rise, raise it and legitimate users are locked out, and the point where those cross moves with lighting, camera, and the composition of the enrolled population. One-to-one verification and one-to-many identification are also different problems. With a gallery of N identities, a per-comparison false accept rate accumulates across every comparison in the search, so a threshold that is defensible for verifying a claimed identity is not defensible for picking one out of a directory.

Presentation attack detection has its own vocabulary and its own test standard. ISO/IEC 30107-3 defines how PAD is evaluated and gives the terms that make claims comparable: APCER for attacks accepted as genuine, BPCER for genuine attempts rejected. Attack classes are not interchangeable. A printed photo, a screen replay, a recorded video, and a mask defeat different checks, and challenge-response prompts such as a blink or a head turn raise the cost of a print attack while doing little against a replay that already contains the requested motion. The harder issue is where the decision is made: an attacker who controls the client can feed frames directly into the pipeline and never involve a camera, so a liveness verdict computed only on the client is a verdict the attacker gets to compute.

Template custody is the third decision and the one with legal weight. An embedding is not a photograph, but it is still biometric data, treated as special category data under GDPR Article 9 and named specifically by several US state biometric privacy laws. The design questions are where the template is stored, whether enrollment can be revoked and redone, what happens when a device is lost, and what the fallback path is, because the fallback sets the real strength of the authentication. On Android there is a hard architectural line here: platform biometrics reached through BiometricPrompt keep the template in secure hardware and never expose it to the application, and a custom camera-based matcher is a separate system that cannot unlock Keystore keys configured to require user authentication.