[ofalvai]

Fixes #108.

Problem

Android rejects a fully downloaded update with Received N bytes, expected -1 when the response has no Content-Length. HttpURLConnection.getContentLength() returns -1 in that case, and the completeness check compares it against the byte count. Proxies that re-chunk responses trigger it, so it depends on the device's network path.

Change

Only compare received and expected bytes when the length is known. This matches iOS, which already skips the check when the expected length is unknown.

Why this is safe

• A chunked response cut off early makes HttpURLConnection throw an IOException in the read loop, so truncation still fails.
• A known Content-Length that doesn't match is still rejected.
• Zip handling, bundle lookup, hash verification and optional signature checks still run after the download.

Out of scope

Progress events still report totalBytes: -1 for these responses, as they did before. The JS side is not touched here.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

A critical validation gap allows an empty HTTP 200 response without Content-Length to be staged as the next app bundle without hash or signature verification.

1 open issue

• Reject empty downloads before staging an update · New

What changed in this PR

Fixes #108 by allowing Android CodePush downloads without a Content-Length header, including responses re-chunked by proxies.

Changes:

• Compares received and expected bytes only when the expected length is known.
• Documents why unknown lengths are accepted and truncated chunked responses still fail during reading.
• Leaves JavaScript progress reporting unchanged.

File	Description
android/​app/​src/​main/​java/​com/​microsoft/​codepush/​react/​CodePushUpdateManager.java	Guards the download-length check and adds an explanatory comment.

_{Review effort: Balanced}