Re: [mono-android] failed to build aapt.exe exited with code 1
Thanks Jonathan The error was - it was objecting to a graphics file which had spaces in the name. You might ask why this worked on previous builds? Well I remember once just after updating the android-sdk using monodevelop instead of VS2010. It appears that MonoDevelop has changed the build flags on several files from none to content or build. The offending graphics file was not part of this project but had acquired content flag. Thanks for your pointer - it helped enormously John Murray -Original Message- From: Jonathan Pryor [mailto:j...@xamarin.com] Sent: 29 August 2012 21:56 To: j...@murray.gb.com; Discussions related to Mono for Android Subject: Re: [mono-android] failed to build aapt.exe exited with code 1 On Aug 29, 2012, at 4:37 PM, John Murray wrote: > Can anyone help - I'm desperate Enable diagnostic MSBuild output: Tools > Options... > Projects and Solutions > Build and Run > MSBuild project build output verbosity: Diagnostic Clean + Rebuild your solution. The MSBuild output is visible in View > Output pad. Look through the MSBuild output and look for "aapt"; the actual aapt-generated error should be (somewhere) in there. What is it? - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
[mono-android] Finish() behaving differently under v404
I've acquired an ICS mobile and started testing on it I've got several subordinate activities where there is a cancel button which use Finish() to end the activity. On the v404 machine this returns right to the beginning and appears to restart the app including splash screen (although data entered in fields in main activity is retained) whereas on v2.3 machines this does not happen. After 'Finish()' one is returned to the calling point in the main activity I have also tried this behaviour on the emulator - using a v2.2 emulator all happens as planned Also surprisingly using a v4.03 emulator everything goesto plan but on my xperia with v4.04 when finish is called not only the subordinate activity (a simple form) is killed but also the main app seems to be killed and starts again with teh splash screen and oncreate method Indeed this behaviour happens regardless of my Cancel button calling Finish() it happens on the back button as well from a subordinate Activity Why might v 4.04 behave differently and what can be done to restore the v2.3 behaviour in v4.04 John Murray ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
[mono-android] Cancelling download updates nukes VS2012
Hi guys, I am on latest v4.2.5. When I start VS2012 I am being offered to download a new version of 4.2.4. Now, if I click Download and then either download or cancel download it is OK. But if I click Cancel on the update dialog then VS2012 goes into a deep comma - only forced close helps. VS2010 doesn't offer the "upgrade". Miha ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] Binding Services - casting interface on service connection fails
Thanks to that Java file my C# function now works perfectly. Thanks for
that!! As such I don't need to plug in the jar file. I can't believe I had
to do a _data.WriteInt(1) to make it work.
public Bundle SendBillingRequest(Bundle bundle)
{
Parcel _data = Parcel.Obtain();
Parcel reply = Parcel.Obtain();
Bundle replyBundle = null;
bool bRes = false;
try
{
_data.WriteInterfaceToken(DESCRIPTOR);
if (bundle!=null)
{
_data.WriteInt(1);
bundle.WriteToParcel(_data,
ParcelableWriteFlags.None);
}
else
_data.WriteInt(0);
bRes =
mRemote.Transact(BillingServiceStub.TRANSACTION_checkBilling, _data, reply,
TransactionFlags.None);
reply.ReadException();
if (reply.ReadInt() != 0)
replyBundle =
Android.OS.Bundle.Creator.CreateFromParcel(reply) as Bundle;
return replyBundle;
}
catch (RemoteException e)
{
var aaa = e.Message;
throw;
}
catch (Java.Lang.IllegalArgumentException e)
{
var aaa = e.Message;
throw;
}
finally
{
_data.Recycle();
reply.Recycle();
}
}
My purchaseObserver is now going nuts with all the hits and is working well.
Can do purchases but I have to iron out some JSON bugs. Too tired to do it
now.
Thanks again. I'm hoping it will be finished soon.
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Binding-Services-casting-interface-on-service-connection-fails-tp5711549p5711657.html
Sent from the Mono for Android mailing list archive at Nabble.com.
___
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] Obfuscator and failed GenerateJavaStubs
On Aug 30, 2012, at 2:44 AM, Igor Russkih wrote: > C:\Program Files\MSBuild\Novell\Novell.MonoDroid.Common.targets(690,3): > error MSB4018: The "GenerateJavaStubs" task failed unexpectedly. > C:\Program Files\MSBuild\Novell\Novell.MonoDroid.Common.targets(690,3): > error MSB4018: System.ApplicationException: Failed to create JavaTypeInfo for > class: ab ---> System.InvalidOperationException: The Name property must be a > fully qualified 'package.TypeName' value, and no package was found for 'ab'. Java.Lang.Object subclasses only need to contain a package if their name will be used in AndroidManifest.xml. (Android!!! /me shakes hand in air.) > Is it possible to do some 'normalization' of symbols when generating .java - > to support this? I'm not sure. Obfuscators can potentially rename ~everything (class names, method names, field names). If your obfuscator were to process Mono.Android.dll, it could then rename virtual methods in all subclasses; I'm sure this is "do-able", and would result in semantically valid IL (as long as all assemblies were corrected). The problem is the Mono.Android.dll implementation which looks up many methods via Reflection, by-name, and if these methods are renamed then all bets are off and things will break horribly. For example, while we could normalize type names so that they're valid Java identifiers, will method names get screwed up? I suspect not -- the method names are retrieved from the [Register] custom attribute, which (presumably) the obfuscator will leave alone, so normalizing Java type names is something that could be done. Would that be effective? I don't know. - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
