Bug 6117 - When deploying to Android 4.1, you get "Data at the root level is invalid. Line 1, position 1."
Summary: When deploying to Android 4.1, you get "Data at the root level is invalid. Li...
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.2.x
Hardware: Macintosh Mac OS
: --- major
Target Milestone: ---
Assignee: Bugzilla
: 6111 6215 ()
Depends on:
Reported: 2012-07-13 15:16 UTC by Chris Hardy [MSFT]
Modified: 2015-02-27 20:19 UTC (History)
9 users (show)

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

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:

Comment 1 Jonathan Pryor 2012-07-13 15:22:26 UTC
Google has apparently changed the permissions of /data/system/packages.xml so that it is no longer readable on Android 4.1/Jelly Bean:

> Arguments: -s 0149CC841201B01C shell cat /data/system/packages.xml
> [STDOUT] /system/bin/sh: cat: /data/system/packages.xml: Permission denied
> [ERROR: TryGetPackageList] TryGetPackageList failed '/data/system/packages.xml': System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1.
>    at System.Xml.XmlTextReaderImpl.Throw(Exception e)

 We'll need to find an alternate way to get package version information from the device.

This might be a dup of Bug #6111. What confuses me is that #6111 reports that package installation continues to work, while in this bug package installation fails. Is the difference due to the IDE?

Note: the package installation failure reported here happens under both MonoDevelop and Visual Studio.
Comment 2 Jonathan Pryor 2012-07-13 15:27:11 UTC
The probable fix:

Instead of grabbing packages.xml to determine package version information, we should add a BroadcastReceiver + Activity to the Mono.Android.DebugRuntime package. The Activity would immediately call Activity.Finish(); the purpose is to launch it so that the BroadcastReceiver can receive broadcasts in Android 3.0+.

The BroadcastReceiver could then be invoked via `adb shell am broadcast ...`, would accept the package name as an argument, and would return the package's version via setResult() (which iirc is printed to the console, allowing `adb` to display it). The package version info should be obtainable from PackageInfo.versionCode:

Comment 7 Jonathan Pryor 2012-07-19 18:10:08 UTC
Core installation support in commit: b8a95de7

This allows `MSBuild /t:Install ...` to target API16 devices
Comment 8 Aaron Bockover 2012-07-20 14:23:50 UTC
*** Bug 6215 has been marked as a duplicate of this bug. ***
Comment 9 Jonathan Pryor 2012-07-20 15:34:50 UTC
VS support in commit a4065d97.
Comment 10 Jonathan Pryor 2012-07-29 23:21:47 UTC
*** Bug 6111 has been marked as a duplicate of this bug. ***
Comment 11 Aaron Bockover 2012-07-31 14:39:40 UTC
When will this be fixed in MonoDevelop?

I would think this could be easily patched for the sake of making a bugfix release without having to use the PackageInfo APIs described above simply by invoking some commands through adb shell:

$ adb shell pm list packages -f com.rdio.android.ui    

$ adb shell ls -al /data/app/com.rdio.android.ui-1.apk
-rw-r--r-- system   system   10151908 2012-07-29 09:52 com.rdio.android.ui-1.apk

As an example. As I understand it, the previous method just the installed packages list from the XML file behind which this command is powered.

This is completely blocking device debugging for me.
Comment 12 Jonathan Pryor 2012-07-31 14:55:04 UTC
This is now fixed in MonoDevelop: you need


As for the PacakageInfo APIs, the issue is twofold:

1. We "need" package version information to determine whether or not the packages on the device need to be upgraded, for example if your device has 4.2.4 Mono.Android.DebugRuntime and you upgraded your development machine to 4.2.5, we need to upgrade the device to use 4.2.5 as well. (Things can and will break if they're out of sync.)

We used /data/system/packages.xml to get this information, which is no longer readable in API16.

2. Some devices haven't supported /data/system/packages.xml, and we did have `adb shell pm list packages` output parsing. Unfortunately, these devices are encountered so rarely that the fallback support was buggy and didn't work properly.

Even if the fallback support did work, it would emit a message similar to "unable to determine installed package versions," which isn't entirely actionable (by the developer) and could result in obscure runtime errors if packages were out of sync.
Comment 13 dbh1997 2012-08-05 23:04:52 UTC
Getting closer.  Between and 4.2.5 the package is sent and runs on the device loaded with Droid 4.1.1.  But...  I have to always delete the previous first, otherwise it just re-runs what's already on the device.

Also, crashes very frequently now when debugging.  Below is the top of the call-stack (full has been submitted numerous times).

Anything known that I can be doing different to get around either issue?


System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.AggregateException: One or more errors occurred. ---> System.OperationCanceledException: The operation was canceled.
   at Mono.AndroidTools.Internal.AdbClientTaskExtensions.<>c__DisplayClass19.<Cleanup>b__18(Task t)
   at System.Threading.Tasks.Task.<>c__DisplayClassb.<ContinueWith>b__a(Object obj)
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
   --- End of inner exception stack trace ---
   at Mono.AndroidTools.AndroidDevice.<>c__DisplayClass2.<RunShellCommand>b__1(Task t)
   at System.Threading.Tasks.Task.<>c__DisplayClasse`1.<ContinueWith>b__d()
   at System.Threading.Tasks.Task`1.InvokeFuture(Object futureAsObj)
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
   --- End of inner exception stack trace ---
Comment 14 Mikayla Hutchinson [MSFT] 2012-08-18 20:08:49 UTC
Dave, that issue is tracked in bug 6366. We're still testing/fixing MD 3.0.4.x before we mark it stable.