1079318 - Replace the Kitkat recovery images with Firefox OS versions

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Patryk Adamczyk [:patryk] UX]

We need to create Firefox versions of these images as they are missing and required by the “recovery menu”.
Without them we note that there file not found errors.

The missing files are stored here (in Android).
KitKat/.. /bootable/recovery/res/images/error_text.png
KitKat/.. /bootable/recovery/res/images/erasing_text.png
KitKat/.. /bootable/recovery/res/images/stage_empty.png
KitKat/.. /bootable/recovery/res/images/stage_fill.png
KitKat/.. /bootable/recovery/res/images/no_command_text.png
KitKat/.. /bootable/recovery/res/images/installing_text.png

Comment 1

[Patryk Adamczyk [:patryk] UX]

Amy please attach the required images to the bug.

Comment 2

[Amy Lee [:amylee] UX]

Attachment: Recovery_Images.zip

Hi Patryk, 

Here are the requested images.

Comment 3

[Patryk Adamczyk [:patryk] UX]

^^^

Comment 4

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

I'm not so familiar with this and I talked with Alexandre last night about this and hope he can give us more info about it.

Alexandre?

Thanks in advance :)

Comment 5

[:gerard-majax]

We do have most of them for the Flame KK recovery. But as far as I know there are still issues with recovery itself: last time I tried, the display was all broken.

> LC_ALL=C ls bootable/recovery/res/images/{error_text,erasing_text,stage_empty,stage_fill,no_command_text,installing_text}.png
> ls: cannot access bootable/recovery/res/images/stage_empty.png: No such file or directory
> ls: cannot access bootable/recovery/res/images/stage_fill.png: No such file or directory
> -rw-rw-r-- 1 alex alex 31K Sep 13 19:18 bootable/recovery/res/images/erasing_text.png
> -rw-rw-r-- 1 alex alex 18K Sep 13 19:18 bootable/recovery/res/images/error_text.png
> -rw-rw-r-- 1 alex alex 66K Sep 13 19:18 bootable/recovery/res/images/installing_text.png
> -rw-rw-r-- 1 alex alex 40K Sep 13 19:18 bootable/recovery/res/images/no_command_text.png

This should be merged in https://github.com/mozilla-b2g/platform_bootable_recovery, in the proper branch.

But I think that most of people will not use a rebuilt recovery and instead the one flashed from partner's images, so this should also be picked up by partners. Viral probably can help us finding the proper contact and replies for all of this.

Comment 6

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Attachment: patch for platform_bootable_recovery/v2.1

Hey Michael,
I'm not sure that this is the way that we need to do this but hope if is not you can suggest us what we need to do. Thanks in advance :)

Comment 7

[viral [:viralwang]]

(In reply to Alexandre LISSY :gerard-majax from comment #5)
> We do have most of them for the Flame KK recovery. But as far as I know
> there are still issues with recovery itself: last time I tried, the display
> was all broken.
> 
Yes, I just try it again with v184 but display still abnormal (all black in my case)
> 
> This should be merged in
> https://github.com/mozilla-b2g/platform_bootable_recovery, in the proper
> branch.
> 
> But I think that most of people will not use a rebuilt recovery and instead
> the one flashed from partner's images, so this should also be picked up by
> partners. Viral probably can help us finding the proper contact and replies
> for all of this.
I will keep following the recovery repository we build from github in bug 1067005.

But if we would like to replace the recovery images in partner's build firstly, I think Wesly can help.

Comment 8

[Wesly Huang (EPM)]

Hi Youlong:

Would yo help follow comment#0's path to add these 6 files (in Recovery_Images.zip) in all future releases? Thanks.

Comment 9

[Wesly Huang (EPM)]

I will also update our tracking list to include this one.

Comment 10

[viral [:viralwang]]

(In reply to viral [:viralwang] from comment #7)
> (In reply to Alexandre LISSY :gerard-majax from comment #5)
> > We do have most of them for the Flame KK recovery. But as far as I know
> > there are still issues with recovery itself: last time I tried, the display
> > was all broken.
> > 
> Yes, I just try it again with v184 but display still abnormal (all black in
> my case)
It should be all blue, not black :(

Comment 11

[youlong.jiang]

(In reply to Wesly Huang from comment #9)
> I will also update our tracking list to include this one.

hi all -

we found replace resource from recovery_images.zip into code build, not work. pls help to confirm image  parameter satisfy recovery request.

tks.

Comment 12

[Wesly Huang (EPM)]

Hi Youlong, would you put more detail about the problem you met? Compile time fail? or compile ok but run time problem like phone hang, or jut simply no image on screen?

Comment 13

[youlong.jiang]

(In reply to Wesly Huang from comment #12)
> Hi Youlong, would you put more detail about the problem you met? Compile
> time fail? or compile ok but run time problem like phone hang, or jut simply
> no image on screen?

Dear wesly -

yep, just simply no image on screen, and more info as follow

image paramters in log:
[color_type:2][bit_depth:8][channels:3]

check condition in code:
recovery/minui/resources.c-->L272
(bit_depth == 8 &&
(channels == 1 && color_type == PNG_COLOR_TYPE_GRAY))

tks.

Comment 14

[Wesly Huang (EPM)]

Hi Patryk:

Per above comment it looks to me there is something strange for those image files, would you help check and advice? Thanks.

Comment 15

[Patryk Adamczyk [:patryk] UX]

I think I know the problem... these images are PNG 24bit but it appears we need PNG 8 bit. Amy will attach new lower bit depth images.

Comment 16

[Amy Lee [:amylee] UX]

Attachment: Recovery_Images.zip

Hi, 

I've attached the images as 8 bit pngs. Let me know if you need anything else.

Comment 17

[Wesly Huang (EPM)]

Thank Amy.

@Youlong: would you help use new image files for the coming SW we are working now? Thank you.

Comment 18

[Michael Wu [:mwu]]

Comment on attachment 8501571 [details] [review]
patch for platform_bootable_recovery/v2.1

FFOS recovery UI assets are stored in librecovery - see https://github.com/mozilla-b2g/librecovery/tree/master/res/images . If you want to update it, I recommend putting it in that repo.

Comment 19

[Wesly Huang (EPM)]

Youlong, you mentioned in phone there is still problem with new images, would you put more detail here for correction?

Comment 20

[youlong.jiang]

(In reply to Wesly Huang from comment #17)
> Thank Amy.
> 
> @Youlong: would you help use new image files for the coming SW we are
> working now? Thank you.

hi wesly -

as we talked in phone, also have no solution to check if integrate these file success per UI. if just verify file system per adb, it's ok.

tks.

Comment 21

[youlong.jiang]

we don't know how to show these pictures.

Comment 22

[xiaomanwang]

Dears,

More details are attached as below:

LoadLocalizedBitmap(...) and LoadBitmap(...) are two different functions to load PNG files in recovery mode. LoadLocalizedBitmap is used to load these newly added PNG files by default(other PNGs are loaded by LoadBitmap). 

These newly added PNG file format are: 
bit_depth=8, channels=1, color_type=3(it might be PNG_COLOR_TYPE_RGBA或者PNG_COLOR_TYPE_PALETTE) 


And the "file format check" in LoadLocalizedBitmap is like below:
if (!(bit_depth == 8 &&
          (channels == 1 && color_type == PNG_COLOR_TYPE_GRAY))) {
        LOGE("bit:%d,channel:%d,color:%d\n", bit_depth, channels,color_type);
        return -7;
        goto exit;
    }
===> The color_type mismatch, so it will return error -7.

The format check in LoadBitmap:
if (!(bit_depth == 8 &&
          ((channels == 3 && color_type == PNG_COLOR_TYPE_RGB) || 
           (channels == 4 && color_type == PNG_COLOR_TYPE_RGBA) ||
           (channels == 1 && (color_type == PNG_COLOR_TYPE_PALETTE ||
                              color_type == PNG_COLOR_TYPE_GRAY))))) {
        return -7;
        goto exit;
    }
===> So the PNG files can be loaded by LoadBitmap sucessfully.

We try to load those newly added PNG via LoadBitmap instead of LoadLocalizedBitmap , no error occurred. But we have no idea about how to operate to make those newly added PNG displaying in the screen UI?

Thanks a lot!

Comment 23

[Wesly Huang (EPM)]

Hi Patryk:

Per comment#22 T2M need some code change in order to use those image files, do you know if it is as your expectation? (I though they can simply put those images and it will work naturally?)

And would you suggest how they can verify those images are correctly used in SW? What's the expected result with these images? If possible would you take a short video from other device with correctly set images?

Thank you.

Comment 24

[Patryk Adamczyk [:patryk] UX]

Can you please attach a video showing how these images should work. Thanks!

Comment 25

[Amy Lee [:amylee] UX]

Attachment: loading_animation.zip

Hi, 

I've uploaded a video to show the loading animation for reference.

Comment 26

[xiaomanwang]

(In reply to Amy Lee [:amylee] from comment #25)
> Created attachment 8506303 [details]
> loading_animation.zip
> 
> Hi, 
> 
> I've uploaded a video to show the loading animation for reference.

Hi Amy, 

Thanks for your video. 

I still have some unclear points. which PNG images used in the video(seems no newly added PNG)? and what did you do before that UI appeared?

Could you give a much more longer video which recorded from the recovery entry UI?

Thanks so much!

Comment 27

[Amy Lee [:amylee] UX]

Attachment: FOTA pngs.zip

Hi, 
 
I've attached the pngs that were used in the loading animation. Please reference the current booting animation as a guide. We are really just swapping out the andriod graphics and replacing them with FFOS graphics, the animation sequence should be the same. Please let me know if you have anymore questions.

Comment 28

[Wesly Huang (EPM)]

XiaoMa, would you help try again? And let Amy know if still a problem, thank you.

Comment 29

[youlong.jiang]

(In reply to Wesly Huang from comment #28)
> XiaoMa, would you help try again? And let Amy know if still a problem, thank
> you.

hi wesly -

from my view, we don't make this issue clear on both sides. the animation effect of our version have reach the target that video shows. so pls verify this problem just on v188 and not append ptv build first. we'll step forward according to the test result.

tks.

Comment 30

[Wesly Huang (EPM)]

Thank Youlong's confirmation.


Hi Amy and Patryk:

It's from comment#22 that T2M asked how to verify the animation work, and now they confirmed (in comment#29) that SW vv188 has what Amy mentioned in comment#27. So would you double verify with v188 then close this issue if it reaches your expectation? Thanks.

Comment 31

[Amy Lee [:amylee] UX]

Hi,

Can you provide a video of the screens/animations that need to be reviewed? Thanks

Comment 32

[Amy Lee [:amylee] UX]

(In reply to Amy Lee [:amylee] from comment #31)
> Hi,
> 
> Can you provide a video of the screens/animations that need to be reviewed?
> Thanks

Comment 33

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #31)
> Hi,
> 
> Can you provide a video of the screens/animations that need to be reviewed?
> Thanks

hi Amy -

in my opinion, you should do this for us. what's more you provided a video but it's the same with current version effect. so we just wanna you to double confirm if issue fixed on v188.

tks.

Comment 34

[Amy Lee [:amylee] UX]

(In reply to youlong.jiang from comment #33)
> (In reply to Amy Lee [:amylee] from comment #31)
> > Hi,
> > 
> > Can you provide a video of the screens/animations that need to be reviewed?
> > Thanks
> 
> hi Amy -
> 
> in my opinion, you should do this for us. what's more you provided a video
> but it's the same with current version effect. so we just wanna you to
> double confirm if issue fixed on v188.
> 
> tks.

Hi,

When I reviewed the recovery screen, the background image looks stretched out. I suspect the wrong sized graphics are being used. I had provided 320x480 and 480x854 (flame size) graphics. Since we have devices in several different screen resolutions, I think it might be more efficient that the background be changed to a solid black colour (#OOOOOO) to eliminate the risk of wrong image sizes being used and having to provide graphics for numerous screen sizes.

Thanks

Comment 35

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #34)
> (In reply to youlong.jiang from comment #33)
> > (In reply to Amy Lee [:amylee] from comment #31)
> > > Hi,
> > > 
> > > Can you provide a video of the screens/animations that need to be reviewed?
> > > Thanks
> > 
> > hi Amy -
> > 
> > in my opinion, you should do this for us. what's more you provided a video
> > but it's the same with current version effect. so we just wanna you to
> > double confirm if issue fixed on v188.
> > 
> > tks.
> 
> Hi,
> 
> When I reviewed the recovery screen, the background image looks stretched
> out. I suspect the wrong sized graphics are being used. I had provided
> 320x480 and 480x854 (flame size) graphics. Since we have devices in several
> different screen resolutions, I think it might be more efficient that the
> background be changed to a solid black colour (#OOOOOO) to eliminate the
> risk of wrong image sizes being used and having to provide graphics for
> numerous screen sizes.
> 
> Thanks

hi Amy, wesly -

so, the problem you think is graphics size not match the resolution of the screen under recovery mode, and, what you want now is delete picture from system and make it black in background, right?

pls correct me if has any problem.

tks.

Comment 36

[Amy Lee [:amylee] UX]

(In reply to youlong.jiang from comment #35)
> (In reply to Amy Lee [:amylee] from comment #34)
> > (In reply to youlong.jiang from comment #33)
> > > (In reply to Amy Lee [:amylee] from comment #31)
> > > > Hi,
> > > > 
> > > > Can you provide a video of the screens/animations that need to be reviewed?
> > > > Thanks
> > > 
> > > hi Amy -
> > > 
> > > in my opinion, you should do this for us. what's more you provided a video
> > > but it's the same with current version effect. so we just wanna you to
> > > double confirm if issue fixed on v188.
> > > 
> > > tks.
> > 
> > Hi,
> > 
> > When I reviewed the recovery screen, the background image looks stretched
> > out. I suspect the wrong sized graphics are being used. I had provided
> > 320x480 and 480x854 (flame size) graphics. Since we have devices in several
> > different screen resolutions, I think it might be more efficient that the
> > background be changed to a solid black colour (#OOOOOO) to eliminate the
> > risk of wrong image sizes being used and having to provide graphics for
> > numerous screen sizes.
> > 
> > Thanks
> 
> hi Amy, wesly -
> 
> so, the problem you think is graphics size not match the resolution of the
> screen under recovery mode, and, what you want now is delete picture from
> system and make it black in background, right?
> 
> pls correct me if has any problem.
> 
> tks.

Hi, 

Yes, I think the 320x480 images are being used instead of the flame sized images. In order to elminate the risk of this happening on different devices, please remove the background images and make the background colour black (#000000). Thanks

Comment 37

[youlong.jiang]

ok, we'll try to fix this problem in next version.

tks.

Comment 38

[Wesly Huang (EPM)]

Hi Patryk/Amy:

We (T2M Youlong and me) re-visit and discussed this issue today and guess there might be some miscommunication above.

Anyway here I would like get your support to double confirm 1 thing: is the issue you reported (missing recovery image) still be seen w/ a "base" v188 image? (just flash v188 SW to phone, not a pvt build, and no shallow flash any gecko/gaia above it) Because from my discussion w/ T2M Youlong we thought the way recovery works (ex: via FOTA upgrade or reset phone) in v188 base image, should aligns to your original expectation (as the animation Amy attached)

If current behavior of v188 base image is not as expected, pls kindly let us know the way you tested it and the symptom you see.

PS: we've have a test SW that following suggestion in comment#36 which result in pure black background w/ orange progress bar during T2M's FOTA process, looks really strange and not user-friendly.

Thank you.

Comment 39

[Amy Lee [:amylee] UX]

Attachment: Recovery_Mode_Edits.png

Hi Wesly, 

I've attached the screens that I see in recovery mode with a v188 base image. I've also highlighted edits to the screens. 

Edits:

1. Is it possible to change the font to Fira Sans Regular? This is to maintain consistency with the rest of the OS. 

2. I've highlighted colour changes to the fonts so it aligns with the colour palette in the OS. 

3. Please remove the background graphics (including the loading screen graphic) and make the background #333333 (Dark Grey). This also aligns with our current colour palette in the OS. The current background graphics makes the screen look busy and the text is hard to see. The graphic also appears stretched and not properly sized. In order to eliminate these issues, I feel background graphics should be removed in recovery mode. As for the loading bar screen, it seems that the loading time is fairly short and it seems unnecessary to have a loading bar graphic in the background which adds to the clutter of the screen.

Please let me know if any of this is unclear. Thanks

Comment 40

[xiaomanwang]

Dear Amy,

On comment#39, you suggested "3.Please remove the background graphics (including the loading screen graphic) and make the background #333333 (Dark Grey)". And in the attached file Recovery_Mode_Edits.png [attachment 8535747 [details]], you suggested "4. Remove the background and make the background #FFFFFF in all recovery screen". 

So, what's the background should be?

Thanks!

Comment 41

[Amy Lee [:amylee] UX]

(In reply to xiaomanwang from comment #40)
> Dear Amy,
> 
> On comment#39, you suggested "3.Please remove the background graphics
> (including the loading screen graphic) and make the background #333333 (Dark
> Grey)". And in the attached file Recovery_Mode_Edits.png [attachment 8535747 [details]
> [details]], you suggested "4. Remove the background and make the background
> #FFFFFF in all recovery screen". 
> 
> So, what's the background should be?
> 
> Thanks!

Hi

Please make it #333333. Thanks!

Comment 42

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #41)
> (In reply to xiaomanwang from comment #40)
> > Dear Amy,
> > 
> > On comment#39, you suggested "3.Please remove the background graphics
> > (including the loading screen graphic) and make the background #333333 (Dark
> > Grey)". And in the attached file Recovery_Mode_Edits.png [attachment 8535747 [details]
> > [details]], you suggested "4. Remove the background and make the background
> > #FFFFFF in all recovery screen". 
> > 
> > So, what's the background should be?
> > 
> > Thanks!
> 
> Hi
> 
> Please make it #333333. Thanks!

hi Amy -

about request#1, per discuss with wesly by phone, we don't think it's a good idea to integrate more font resource into system that would take more memory space. then what you think and pls append comments

request#2,#3, we'll modify font colour according the value you provided in next version

request#4, we found that UI is not suitable when fota upgrade under recovery after reset background. then also unvaliable. pls check attachment pic in detail.

tks.

Comment 43

[youlong.jiang]

Attachment: fota_recovery_ui

Comment 44

[Amy Lee [:amylee] UX]

Attachment: FOTA_Animation_pngs.zip

Hi, 

I've attached progress bar animation pngs with an updated #333333 background colour to match the screen. Please replace the current ones with these.

As for the font change request, shouldn't we already have Fira Sans in the system since it's used for the OS? Or is it the lack of compression of the font that is the issue? I took a look at fonts available in master (https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk). If this list is accurate and we can't use Fira Sans can we use a font that isn't mono spaced such as DroidSans? 

Thanks

Comment 45

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #44)
> Created attachment 8537886 [details]
> FOTA_Animation_pngs.zip
> 
> Hi, 
> 
> I've attached progress bar animation pngs with an updated #333333 background
> colour to match the screen. Please replace the current ones with these.
> 
> As for the font change request, shouldn't we already have Fira Sans in the
> system since it's used for the OS? Or is it the lack of compression of the
> font that is the issue? I took a look at fonts available in master
> (https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk). If this list is
> accurate and we can't use Fira Sans can we use a font that isn't mono spaced
> such as DroidSans? 
> 
> Thanks

Dear Amy -

ok. we would check status per including resource you provided.

about font problem, I double confirm resource config in https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk. it's taken in ext4 file system, I don't think it works in recovery. 

tks.

Comment 46

[youlong.jiang]

(In reply to youlong.jiang from comment #45)
> (In reply to Amy Lee [:amylee] from comment #44)
> > Created attachment 8537886 [details]
> > FOTA_Animation_pngs.zip
> > 
> > Hi, 
> > 
> > I've attached progress bar animation pngs with an updated #333333 background
> > colour to match the screen. Please replace the current ones with these.
> > 
> > As for the font change request, shouldn't we already have Fira Sans in the
> > system since it's used for the OS? Or is it the lack of compression of the
> > font that is the issue? I took a look at fonts available in master
> > (https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk). If this list is
> > accurate and we can't use Fira Sans can we use a font that isn't mono spaced
> > such as DroidSans? 
> > 
> > Thanks
> 
> Dear Amy -
> 
> ok. we would check status per including resource you provided.
> 
> about font problem, I double confirm resource config in
> https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk. it's taken in
> ext4 file system, I don't think it works in recovery. 
> 
> tks.

hi Amy -

we think it's ok after replace resource you provided, pls find attach in detail. but it's so monotone that not suggest to change it. so what you think?

tks.

Comment 47

[youlong.jiang]

Attachment: modify_fota_progress

Comment 48

[Amy Lee [:amylee] UX]

(In reply to youlong.jiang from comment #46)
> (In reply to youlong.jiang from comment #45)
> > (In reply to Amy Lee [:amylee] from comment #44)
> > > Created attachment 8537886 [details]
> > > FOTA_Animation_pngs.zip
> > > 
> > > Hi, 
> > > 
> > > I've attached progress bar animation pngs with an updated #333333 background
> > > colour to match the screen. Please replace the current ones with these.
> > > 
> > > As for the font change request, shouldn't we already have Fira Sans in the
> > > system since it's used for the OS? Or is it the lack of compression of the
> > > font that is the issue? I took a look at fonts available in master
> > > (https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk). If this list is
> > > accurate and we can't use Fira Sans can we use a font that isn't mono spaced
> > > such as DroidSans? 
> > > 
> > > Thanks
> > 
> > Dear Amy -
> > 
> > ok. we would check status per including resource you provided.
> > 
> > about font problem, I double confirm resource config in
> > https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk. it's taken in
> > ext4 file system, I don't think it works in recovery. 
> > 
> > tks.
> 
> hi Amy -
> 
> we think it's ok after replace resource you provided, pls find attach in
> detail. but it's so monotone that not suggest to change it. so what you
> think?
> 
> tks.

Hi, 

Can you provide some context as to how the user arrives to this screen? If you can provide a video showing the previous screens and how the user got to this screen, that would be very helpful. 

Thanks

Comment 49

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #48)
> (In reply to youlong.jiang from comment #46)
> > (In reply to youlong.jiang from comment #45)
> > > (In reply to Amy Lee [:amylee] from comment #44)
> > > > Created attachment 8537886 [details]
> > > > FOTA_Animation_pngs.zip
> > > > 
> > > > Hi, 
> > > > 
> > > > I've attached progress bar animation pngs with an updated #333333 background
> > > > colour to match the screen. Please replace the current ones with these.
> > > > 
> > > > As for the font change request, shouldn't we already have Fira Sans in the
> > > > system since it's used for the OS? Or is it the lack of compression of the
> > > > font that is the issue? I took a look at fonts available in master
> > > > (https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk). If this list is
> > > > accurate and we can't use Fira Sans can we use a font that isn't mono spaced
> > > > such as DroidSans? 
> > > > 
> > > > Thanks
> > > 
> > > Dear Amy -
> > > 
> > > ok. we would check status per including resource you provided.
> > > 
> > > about font problem, I double confirm resource config in
> > > https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk. it's taken in
> > > ext4 file system, I don't think it works in recovery. 
> > > 
> > > tks.
> > 
> > hi Amy -
> > 
> > we think it's ok after replace resource you provided, pls find attach in
> > detail. but it's so monotone that not suggest to change it. so what you
> > think?
> > 
> > tks.
> 
> Hi, 
> 
> Can you provide some context as to how the user arrives to this screen? If
> you can provide a video showing the previous screens and how the user got to
> this screen, that would be very helpful. 
> 
> Thanks

hi Amy -

it's fota upgrade process. then I think it's hard and complex to construct this process for you. just simple words appended to describe

1. flash v18D and patched recovery image
2. install diff package into device we provided
3. echo command into file system and reboot phone

tks.

Comment 50

[Wesly Huang (EPM)]

Hi Amy:

Suggest you can get a Flame and flash v123 SW then check for system update, you will receive FOTA notification and can see current FOTA upgrade process, there will be 2 places to show progress bar

1. when download FOTA package
2. after phone restart, applying the FOTA package

The picture Youlong attached (comment#47), is the 2nd case when progress bar appear, compared w/ existing one you will see the proposed one looks quite simple. And that's the concern Youlong raised in comment#46.
And I personal vote will be staying in current design.

@Youlong:

as discussed in meeting, pls also help double confirm, if there is any other case that user will meet the screen in comment#47, besides FOTA? Thanks.

Amy to check v123 FOTA process, youlong to check if any other case besides FOTA

Comment 51

[youlong.jiang]

(In reply to Wesly Huang from comment #50)
> Hi Amy:
> 
> Suggest you can get a Flame and flash v123 SW then check for system update,
> you will receive FOTA notification and can see current FOTA upgrade process,
> there will be 2 places to show progress bar
> 
> 1. when download FOTA package
> 2. after phone restart, applying the FOTA package
> 
> The picture Youlong attached (comment#47), is the 2nd case when progress bar
> appear, compared w/ existing one you will see the proposed one looks quite
> simple. And that's the concern Youlong raised in comment#46.
> And I personal vote will be staying in current design.
> 
> @Youlong:
> 
> as discussed in meeting, pls also help double confirm, if there is any other
> case that user will meet the screen in comment#47, besides FOTA? Thanks.
> 
> Amy to check v123 FOTA process, youlong to check if any other case besides
> FOTA

hi wesly -

if remove background pic, also will change UI status of "Reset phone". the effect is as attachment that replace resource Amy provided.

tks.

Comment 52

[youlong.jiang]

Attachment: reset phone

Comment 53

[Wesly Huang (EPM)]

Thank Youlong.

Hi Amy:

per comment#51 then this change will also impact UI during phone reset, which you can perform in "settings-->device information-->more information-->reset phone".

After checking the attachment of comment#52 my personal view is tend to keep current design w/o the change, how do you think?

Comment 54

[Amy Lee [:amylee] UX]

Attachment: New_FOTA_Screen.png

Hi Wesly and Youlong, 

Yes I think it looks too plain with just the grey bar. My original intent was to remove the background graphics in recovery mode and make the background dark grey since in that scenario, there is text on top of the graphics and it was hard to read (comment 39). For FOTA and "Phone Reset" and in situations where there is no text on top of the graphics, I would keep the current design with some visual edits that I have attached here. I have also attached updated graphics to replace the current ones. Let me know if you have any questions or need anything else from me.

Comment 55

[Amy Lee [:amylee] UX]

Attachment: FOTA_Graphics.zip

Updated graphics

Comment 56

[Wesly Huang (EPM)]

Thanks Amy!

@Youlong: pls help check the new attached and let us know if any problem you see to implement it. Thanks!

Comment 57

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #54)
> Created attachment 8542230 [details]
> New_FOTA_Screen.png
> 
> Hi Wesly and Youlong, 
> 
> Yes I think it looks too plain with just the grey bar. My original intent
> was to remove the background graphics in recovery mode and make the
> background dark grey since in that scenario, there is text on top of the
> graphics and it was hard to read (comment 39). For FOTA and "Phone Reset"
> and in situations where there is no text on top of the graphics, I would
> keep the current design with some visual edits that I have attached here. I
> have also attached updated graphics to replace the current ones. Let me know
> if you have any questions or need anything else from me.

hi Amy -

I've checked your attachment and found just overall background resource changed more light. also you mentioned the root cause you plan to modify resource is hard to read text. But from my view, I don't think it's serious and unacceptable. and, if you think it's a problem that how about just modify text colour and not change resource?

tks.

Comment 58

[Amy Lee [:amylee] UX]

(In reply to youlong.jiang from comment #57)
> (In reply to Amy Lee [:amylee] from comment #54)
> > Created attachment 8542230 [details]
> > New_FOTA_Screen.png
> > 
> > Hi Wesly and Youlong, 
> > 
> > Yes I think it looks too plain with just the grey bar. My original intent
> > was to remove the background graphics in recovery mode and make the
> > background dark grey since in that scenario, there is text on top of the
> > graphics and it was hard to read (comment 39). For FOTA and "Phone Reset"
> > and in situations where there is no text on top of the graphics, I would
> > keep the current design with some visual edits that I have attached here. I
> > have also attached updated graphics to replace the current ones. Let me know
> > if you have any questions or need anything else from me.
> 
> hi Amy -
> 
> I've checked your attachment and found just overall background resource
> changed more light. also you mentioned the root cause you plan to modify
> resource is hard to read text. But from my view, I don't think it's serious
> and unacceptable. and, if you think it's a problem that how about just
> modify text colour and not change resource?
> 
> tks.

Hi Youlong, 

I just want to make it clear that these are the following changes I would like to see:

1. Recovery Mode Screen (See attachment in comment 39) - Please remove graphics from background. My issue is having a background graphic with text on top looks like a mistake. The original usage of the graphics was not meant for this screen.

2. FOTA/Reset Phone (See attachment in comment 54) - Please keep graphics but update it with the graphics I provided in comment 55. I had requested a colour change and gradient removal because we are trying to keep a consistent colour palette in the OS and we no longer use gradients.

Youlong, let's arrange a call to make sure things are clear. Thanks

Comment 59

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #58)
> (In reply to youlong.jiang from comment #57)
> > (In reply to Amy Lee [:amylee] from comment #54)
> > > Created attachment 8542230 [details]
> > > New_FOTA_Screen.png
> > > 
> > > Hi Wesly and Youlong, 
> > > 
> > > Yes I think it looks too plain with just the grey bar. My original intent
> > > was to remove the background graphics in recovery mode and make the
> > > background dark grey since in that scenario, there is text on top of the
> > > graphics and it was hard to read (comment 39). For FOTA and "Phone Reset"
> > > and in situations where there is no text on top of the graphics, I would
> > > keep the current design with some visual edits that I have attached here. I
> > > have also attached updated graphics to replace the current ones. Let me know
> > > if you have any questions or need anything else from me.
> > 
> > hi Amy -
> > 
> > I've checked your attachment and found just overall background resource
> > changed more light. also you mentioned the root cause you plan to modify
> > resource is hard to read text. But from my view, I don't think it's serious
> > and unacceptable. and, if you think it's a problem that how about just
> > modify text colour and not change resource?
> > 
> > tks.
> 
> Hi Youlong, 
> 
> I just want to make it clear that these are the following changes I would
> like to see:
> 
> 1. Recovery Mode Screen (See attachment in comment 39) - Please remove
> graphics from background. My issue is having a background graphic with text
> on top looks like a mistake. The original usage of the graphics was not
> meant for this screen.
> 
> 2. FOTA/Reset Phone (See attachment in comment 54) - Please keep graphics
> but update it with the graphics I provided in comment 55. I had requested a
> colour change and gradient removal because we are trying to keep a
> consistent colour palette in the OS and we no longer use gradients.
> 
> Youlong, let's arrange a call to make sure things are clear. Thanks

hi Amy -

the problem is we can't remove background graphics in recovery mode and make graphic update with resource you provided in comment 55 when do fota/reset phone process. they use the same resource.

ok. now is 3:00pm Jan.4 in China time zone. how about 9:30am in tomorrow morning. and pls leave me a call number.

tks.

Comment 60

[Amy Lee [:amylee] UX]

Hi Youlong, 

I'll email you my contact info and we'll discuss. Thanks.

Comment 61

[youlong.jiang]

(In reply to Amy Lee [:amylee] from comment #60)
> Hi Youlong, 
> 
> I'll email you my contact info and we'll discuss. Thanks.

hi Amy -

Per talked on phone, we'll take actions as below:

1. check if possible to correct black overlay with text on top of it, by colour #000000 and 50% opacity change.

2. replace background and process bar resource provided before.

and would feedback asap.

tks.

Comment 62

[xiaomanwang]

Attachment: snapshot_recovery.rar

New snapshot of recovery according to comment#61

Comment 63

[Amy Lee [:amylee] UX]

Attachment: Edits.zip

Hi, 

Here is my feedback and I've also attached visual references:

1. FOTO Installing - The colours in the background graphic don't match the animation bar and gear animation. Can you verify that the correct graphics are being used? (See attachment).

2. Factory Reset - It looks like the error icon is sitting on top of the gear animation. This is incorrect. Graphics shouldn’t be overlapping. If the error icon appears, there should not be a gear animation under it (See attachment).

The colours in the background graphic don't match the animation bar and gear animation. Can you verify that the correct graphics are being used? (See attachment).

---------------------

Once these changes are made, can you make a video of these scenarios so I am able to see the animations? Or if you are able to give me a patch for me to check on the device that would be great.

Thanks

Comment 64

[Amy Lee [:amylee] UX]

Hi, 

I spoke to Michael Wu and he suggests that we update the images on our end to ensure that the changes take effect on the master branch. I've asked Pavel to help with updating the graphics so he can takeover from this point on. 

Thanks everyone for assisting with this

Comment 65

[Amy Lee [:amylee] UX]

Attachment: FiraSans_PNGs.zip

Hi Pavel, 

Is it possible to change the fonts used in recovery mode? See comment 39. 

Michael had provided me this link for the current font being used http://androidxref.com/4.4.2_r2/xref/bootable/recovery/fonts/

It looks like it's calling on png files to display text. I've attached replacement pngs with Fira Sans. Let me know if these are usable since I realize that the font height and line lengths are different. 

Thanks

Comment 66

[Wesly Huang (EPM)]

(In reply to Amy Lee [:amylee] from comment #64)
> Hi, 
> 
> I spoke to Michael Wu and he suggests that we update the images on our end
> to ensure that the changes take effect on the master branch. I've asked
> Pavel to help with updating the graphics so he can takeover from this point
> on. 
> 
> Thanks everyone for assisting with this

Hi Amy: 

I assume w/ this new direction, the new recovery image will only take effect in 1)Mozilla's pvt build, and 2) future SW after FxOS 2.2, and will *not* take effect in 3) T2M's base image, and 4) the case that people take T2M's base image then shallow flash our gecko/gaia (the most common use case I see). Would you help confirm (you may need to check w/ Michale Wu again) this is the expect result? If confirmed then I have no further question and this issue will become pure Mozilla one. Thanks.

Comment 67

[Amy Lee [:amylee] UX]

Hi Wesly,

NI'ing Michael for his input on this. 

 

(In reply to Wesly Huang from comment #66)
> (In reply to Amy Lee [:amylee] from comment #64)
> > Hi, 
> > 
> > I spoke to Michael Wu and he suggests that we update the images on our end
> > to ensure that the changes take effect on the master branch. I've asked
> > Pavel to help with updating the graphics so he can takeover from this point
> > on. 
> > 
> > Thanks everyone for assisting with this
> 
> Hi Amy: 
> 
> I assume w/ this new direction, the new recovery image will only take effect
> in 1)Mozilla's pvt build, and 2) future SW after FxOS 2.2, and will *not*
> take effect in 3) T2M's base image, and 4) the case that people take T2M's
> base image then shallow flash our gecko/gaia (the most common use case I
> see). Would you help confirm (you may need to check w/ Michale Wu again)
> this is the expect result? If confirmed then I have no further question and
> this issue will become pure Mozilla one. Thanks.

Comment 68

[Kai-Zhen Li [:seinlin][:kli]]

You can see the recovery images in this bug look pretty nice.

https://bug1017735.bugzilla.mozilla.org/attachment.cgi?id=8437570

Comment 69

[Michael Wu [:mwu]]

(In reply to Wesly Huang from comment #66)
> I assume w/ this new direction, the new recovery image will only take effect
> in 1)Mozilla's pvt build, and 2) future SW after FxOS 2.2, and will *not*
> take effect in 3) T2M's base image, and 4) the case that people take T2M's
> base image then shallow flash our gecko/gaia (the most common use case I
> see). Would you help confirm (you may need to check w/ Michale Wu again)
> this is the expect result? If confirmed then I have no further question and
> this issue will become pure Mozilla one. Thanks.

We need to handle this issue internally so we can pass these changes to the SoC vendors who will then pass the appropriate changes too all downstream vendors. So in the future, T2M will only need to pull in the latest upstream changes (and maybe make some tweaks) to make the recovery image look correct.

Comment 70

[Wesly Huang (EPM)]

Thanks Michael and Kai-Zhen, clear!

Comment 71

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Attachment: patch for librecovery

Comment 72

[BMO Automation]

Firefox OS is not being worked on