Bug 23823 - Error rendering views with AppCompat
Summary: Error rendering views with AppCompat
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.18.0
Hardware: PC Mac OS
: Highest blocker
Target Milestone: 4.18.1
Assignee: dean.ellis
Depends on:
Reported: 2014-10-14 14:43 UTC by John Miller [MSFT]
Modified: 2014-10-27 13:31 UTC (History)
10 users (show)

Is this bug a regression?: ---
Last known good build:

Test Case (1.53 MB, application/zip)
2014-10-14 14:43 UTC, John Miller [MSFT]
With 4.18 (bad.png) (29.86 KB, image/png)
2014-10-14 14:43 UTC, John Miller [MSFT]
With 4.16 (good.png) (23.55 KB, image/png)
2014-10-14 14:44 UTC, John Miller [MSFT]
Repro Solution (181.02 KB, application/zip)
2014-10-16 14:27 UTC, Jon Dick
Simple app that demonstrates the bug in custom library bindings projects (29.47 KB, application/x-zip-compressed)
2014-10-22 20:04 UTC, David Schwegler

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description John Miller [MSFT] 2014-10-14 14:43:40 UTC
Created attachment 8415 [details]
Test Case


   Theme views are not rendered correctly when using the v7 AppCompat library. 

**Steps to Reproduce:**

   1. Run the attached sample on an emulator with XA 4.18 installed. 

**Actual Results:**

   See the attached image (bad.png).

**Expected Results:**

   See the attached image (good.png).

**Build Date & Platform:**

   XA 4.18

**Additional Information:**

   Downgrading to XA 4.16 produces the expected results (possible workaround)
Comment 1 John Miller [MSFT] 2014-10-14 14:43:58 UTC
Created attachment 8416 [details]
With 4.18 (bad.png)
Comment 2 John Miller [MSFT] 2014-10-14 14:44:37 UTC
Created attachment 8417 [details]
With 4.16 (good.png)
Comment 3 Jon Dick 2014-10-14 15:19:25 UTC
http://forums.xamarin.com/discussion/25110/appcompat-v7-distorted-backgrounds-on-actionbar-and-searchview has some more people with similar issues.
Comment 4 Jonathan Pryor 2014-10-14 15:23:06 UTC
Should be fixed in monodroid/24630451 by excluding .9.png files from the png-crush process.
Comment 6 Jon Dick 2014-10-16 14:27:00 UTC
Created attachment 8435 [details]
Repro Solution

Confirmed, 9-patches still are not drawn correctly even after 24630451

I've followed the output of the .9.png file (even inspecting it in the final .apk built) and the file looks fine at the end of the process, so I don't think it's necessarily an issue with manipulating the .9.png anymore.

I've attached a VERY simple repro.  The monkey should not stretch out as it does, but instead should appear centered on the screen.
Comment 7 Peter Collins 2014-10-21 21:07:46 UTC
@Jon I'm unable to reproduce the failure you've pointed to in Comment #6. The image in that attached project displays centered on the screen for me in both the 4.18 version in the Stable channel, and the latest from master (4dccc2eb).

I do see the original issue described in Comment #1 with these same builds however.
Comment 8 Jonathan Pryor 2014-10-21 22:04:25 UTC
I have narrowed down the problem, though I still don't understand what's happening.

The problem is that 9patch files aren't being recognized as 9patch files.

1. Take Attachment #8415 [details], then add a 9patch file to it.
    I copied abc_textfield_search_selected_holo_light.9.png
    from the support library.

2. Modify MainActivity.OnCreate() to add:

	var d = Resources.GetDrawable (Resource.Drawable.foo);
	Console.WriteLine ("# d.Type={0}", d.GetType ());
	var f = Resources.GetDrawable (Resource.Drawable.abc_textfield_search_selected_holo_light);
	Console.WriteLine ("# f.Type={0}", f.GetType ());

3. Run.


> # d.Type=Android.Graphics.Drawables.NinePatchDrawable
> # f.Type=Android.Graphics.Drawables.BitmapDrawable

abc_textfield_search_selected_holo_light IS a 9patch, yet Resources.GetDrawable() isn't creating a NinePatchDrawable, it's creating a BitmapDrawable. Everything falls apart from there.

Thus, the question: WHY isn't it recognized as a 9patch?
Comment 9 Jonathan Pryor 2014-10-22 13:07:48 UTC
Have a better handle on the problem.

The problem is that 9patch files aren't "just" PNG files. They're *processed* to *remove* the "black lines" around the border, and the information those black lines encode are inserted as a PNG chunk:


`aapt` is responsible for performing this processing.

We can thus define the following validation workflow:

1. Within a project, add a 9patch file as the resource (e.g. Comment #8).

2. Package the project:

    xbuild /t:SignAndroidPackage Proejct.csproj /v:diag > b.txt

3. Compare the file size between the 9patch in (1) to the file in the .apk.

    ls -l Resources/drawable/foo.9.png 
    unzip -l bin/Debug/*-Signed.apk | grep foo


In 4dccc2eb (current master I tested), they DO NOT:

> $ ls -l Resources/drawable/foo.9.png 
> -rw-r--r--+ 1 jon  staff  192 Oct 21 21:45 Resources/drawable/foo.9.png
> $ unzip -l bin/Debug/*-Signed.apk | grep foo
>       192  10-21-14 21:45   res/drawable/foo.9.png

Within our build system, the <Crunch/> task is responsible for performing this crunching; via b.txt:

> Task "Crunch"
> 	Using task Crunch from Xamarin.Android.Tasks.Crunch, Xamarin.Android.Build.Tasks, Version=, Culture=neutral, PublicKeyToken=null
> 	Crunch Task
> 	  SourceFiles:
> 	    /Users/jon/Downloads/bxc-23823/SearchViewBugDroid/SearchViewBugDroid/obj/Debug/res/layout/main.xml
> 	    /Users/jon/Downloads/bxc-23823/SearchViewBugDroid/SearchViewBugDroid/obj/Debug/res/values/strings.xml
> 	    /Users/jon/Downloads/bxc-23823/SearchViewBugDroid/SearchViewBugDroid/obj/Debug/res/drawable/icon.png
> 	    /Users/jon/Downloads/bxc-23823/SearchViewBugDroid/SearchViewBugDroid/obj/Debug/res/values/styles.xml
> 	    /Users/jon/Downloads/bxc-23823/SearchViewBugDroid/SearchViewBugDroid/obj/Debug/res/drawable/foo.9.png
> 	  ToolPath: /opt/android/sdk-tool/sdk/build-tools/21.0.1/
> 	  ToolExe: aapt
> 	  ResourceRootDirectory: obj/Debug/res/
> 	Tool /opt/android/sdk-tool/sdk/build-tools/21.0.1/aapt execution started with arguments: c -S /var/folders/1y/wwmg3hv5685ft661f5q2w2100000gn/T/rk6o93er.uf3 -C /var/folders/1y/wwmg3hv5685ft661f5q2w2100000gn/T/ktt7fzzr.zvh 
> 	Crunching PNG Files in source dir: /var/folders/1y/wwmg3hv5685ft661f5q2w2100000gn/T/rk6o93er.uf3
> 	To destination dir: /var/folders/1y/wwmg3hv5685ft661f5q2w2100000gn/T/ktt7fzzr.zvh
> 	Tool /opt/android/sdk-tool/sdk/build-tools/21.0.1/aapt execution finished.
> Done executing task "Crunch"

For starters, I think there's a bug in the <Crunch/> task, as e.g. obj/Debug/res/drawable/foo.9.png is NOT updated (and that's what winds up in the .apk, via the above `unzip` output). FOR STARTERS, this needs to be investigated.

Then there's the AppCompat angle: NOT ONLY do the app resources need to be crunched, but ALSO *all* the resources from any referenced LIBRARY projects, such as the Xamarin.Android.Support.v7 component!

Even if the App resources were properly updated, because <Crunch/> is not processing the (nearly 300) images coming from the AppCompat library, things would STILL be broken.

Dean: Please investigate the <Crunch/> task semantics and crunching of library resources for inclusion into the final .apk.
Comment 11 dean.ellis 2014-10-22 14:50:06 UTC
According to various sites 9 patch files can be processed using aapt manually 

aapt c[runch] [-v] -S input-folder -C output-folder
aapt s[ingleCrunch] [-v] -i input-file -o output-file

This should process the file correctly. 

Additionally we can check they are being correctly processed using the following android code

Bitmap bitmap = BitmapFactory.DecodeStream(stream);
byte[] chunks = bitmap.GetNinePatchChunk();
var result = NinePatch.IsNinePatchChunk(chunks);
Comment 12 David Schwegler 2014-10-22 20:02:47 UTC
Hey Jon/Dean, I think I've run into this bug with our own library bindings projects. 

I've attached a trivial project (NineBindingApp.zip) that shows the issue with two images -- a 9-patch from the app's own project is correctly displayed, while an identical 9-patch from the referenced library bindings project is not.

When you resolve this issue, would you please verify that your fix also fixes binding projects such as mine (I assume it will)? Thanks!
Comment 13 David Schwegler 2014-10-22 20:04:32 UTC
Created attachment 8477 [details]
Simple app that demonstrates the bug in custom library bindings projects
Comment 14 dean.ellis 2014-10-23 17:10:34 UTC
Fixed in monodroid/monodroid-4.18-series/8a7f3488 and in master.

We reverted processing back to the way it was done in 4.16 we'll revisit the build improvements in a future release
Comment 15 Sunil Kumar 2014-10-27 13:31:37 UTC
I have checked this issue and now this issue works fine. I have downloaded the attached sample and run on emulator and we are getting the expected result(Same as good.png mentioned in Bug description). 

Screencast: http://www.screencast.com/t/HsYx3Ps11v

Environment info: 
=== Xamarin Studio ===

Version 5.5.3 (build 6)
Installation UUID: 561c7a69-0a91-4bae-ad7c-f0c79d594337
	Mono 3.10.0 ((detached/e204655)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 310000023

=== Xamarin.Android ===

Version: 4.18.1 (Business Edition)
Android SDK: /Users/tajinder/Desktop/android-sdk-macosx
	Supported Android versions:
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		3.2    (API level 13)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		4.5    (API level 21)
Java SDK: /usr
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Apple Developer Tools ===

Xcode 5.1.1 (5085)
Build 5B1008

=== Xamarin.Mac ===

Version: (Business Edition)

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 3bf072d
Build date: 2014-10-15 21:44:26-0400

=== Build Information ===

Release ID: 505030006
Git revision: fbe3e9453daf6a3bb9a9709ed22bec35f7c9056b
Build date: 2014-10-23 13:08:38-04
Xamarin addins: e44add2b39de4dd57c0742bb2e620dfad84c64c6

=== Operating System ===

Mac OS X 10.8.4
Darwin Tajinders-iMac.local 12.4.2 Darwin Kernel Version 12.4.2
    Mon Jun 17 18:00:12 PDT 2013
    root:xnu-2050.45.8~1/RELEASE_X86_64 x86_64