User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; TCO_20130913150017) Steps to reproduce: Our test engineer test FOTA function. After the device downloaded the package(updata.mar), the package would be uncompress into update.zip. After installed the package and reboot Actual results: The device couldn't enter into system and work fine. The device would be work fine. We compare the package(update.zip) and found the zip is corrupted maybe in downloading or uncompressing. It's different from the correct package. Expected results: We think the FOTA would verify the package first. if zip is a bad package, the install operation would be forbidden.

Hi Zhang Iie, Could you help on the following questions? 1. Is this always reproduced? Which file is corrupted (update.mar or update.zip). 2. Once it happens, can the phone still be used after rebooting? 3. Is this related the v1.1 fixing that using the SD card as the destination for the uncompressed package?

Leo+ this as we want FOTA's to be perfect. This may mostly fall under ZTE for investigation as I do not think we have changed anything related to the FOTA mechanism in 1.1, ccing :dhylands to confirm.

Nothing related to FOTA has changed in ages, as far as I'm aware. The update.mar file has a hash (there are several that you can choose from : md5, sha1, sha256, sha384, sha512) to verify the integrity of what it contains.

Hi Bhavana, In my opinion, I think it should not be the blocker of Leo but the feature question for future version. As my understanding for FOTA, the FOTA flow is the same as it is since 1.0.1. As you mentioned, we want to enhance some functionality on FOTA, but I don't think it is something we can do in short period of time. As far as I know, ZTE is checking if they can do some integrity check as the workaround for v1.1 now. What they will do is to do the checking in the phone recovery mode during the FOTA to prevent corrupted files contained in update.zip that fails the FOTA.

(In reply to Ivan Tsay (:ITsay) from comment #4) > Hi Bhavana, > > In my opinion, I think it should not be the blocker of Leo but the feature > question for future version. As my understanding for FOTA, the FOTA flow is > the same as it is since 1.0.1. As you mentioned, we want to enhance some > functionality on FOTA, but I don't think it is something we can do in short > period of time. As far as I know, ZTE is checking if they can do some > integrity check as the workaround for v1.1 now. What they will do is to do > the checking in the phone recovery mode during the FOTA to prevent corrupted > files contained in update.zip that fails the FOTA. Thanks given the work around I am removing the blocking flag for leo, please renom for koi, if this is a case that we need to handle in our update scenario for future releases.

Pulling qawanted as there's nothing internal Moz QA can do here - this needs to be handled by the partner specifically.

Firefox OS is not being worked on