Here is the target: Create an Android app (Android 4.2) for HTC phones that uses Bluetooth LE to communicate with other BTLE devices. I have to use the HTC proprietary Bluetooth LE java library.
I have done the following:
Created an Java Bindings Library project that uses the "com.htc.android.bluetooth.le.gatt.jar" and "com.broadcom.bt.jar" files. This outputs as expected (I believe) with no modifications to the Metadata.xaml, etc.
Created an Android Class Library that basically translates all of the java binding methods into friendlier methods (ie. Discovery LE devices, provide a list of them, all simple connections, read/write to them). This project builds just fine. I have the reference to the outputted DLL from the binding library in this project.
Created an Android Application (Android 4.2; I would use 4.3 and be done with this, but that's not the objective). This application references the above Android Class library for use.
Problem: As soon as I attempt to build, I get all sorts of errors:
package com.htc.android.bluetooth.le.gatt does not exist
Line 5 : "extends com.htc.android.bluetooth.le.gatt.BleClientProfile"
in HTCBleClientProfile.java
It actually complains about that for all the outputted java files. Slight variations to what is exactly being extended upon.
So I thought, what if I just move over the generated java files that the binding project created? I did that, and all work required for referencing to be right, but ended up with a different errors.
First thing I did was move over the generated class files. All the classes had attributes like the following:
namespace Com.Htc.Android.Bluetooth.LE.Gatt {
// Metadata.xml XPath class reference: path="/api/package[#name='com.htc.android.bluetooth.le.gatt']/class[#name='BleAdapter']"
[global::Android.Runtime.Register ("com/htc/android/bluetooth/le/gatt/BleAdapter", DoNotGenerateAcw=true)]
public partial class BleAdapter : global::Java.Lang.Object {
/*...*/
}
If I left all the classes alone, no *.java file would be generated in the application project, resulting in something like "No Class Found" errors during runtime.
So I adjusted the "DoNoGenerateAcw" to false, which lead to the *.java files to finally generated.
At this point, now I'm getting errors for every constructor that takes in parameters for all those classes I moved in:
Object() in java.lang.object cannot be applied to (com.htc.android.bluetooth.le.gatt.GattID)
That's just one of the many different errors. But they all are the same in one respect: "Object() in java.lang.object cannot be applied to (some type)". So I reverted all the way back to the point of me referencing the DLL (which leads me back to package errors).
Does anyone have an idea of what I could do to resolve this? I have emailed Xamarin for help and also HTC for some possible solutions (like the Java source so I can port it myself to C# for this app).
Thank you in advance!
Related
I am having difficulty building an android app called Commotion Wireless from its source code. This should be a simple matter of importing the project into eclipse and exporting it as an APK.
However upon building I am left with three errors:
two saying "isIBSS cannot be resolved or is not a field" and
one saying "frequency cannot be resolved or is not a field".
The lines of code producing these errors are lines 201, 202 and line 92. If I comment out these lines of code then I can generate an APK just fine, though obviously the app doesn't work as intended with these lines missing.
My impression was that these errors arose due to Android not supporting ad-hoc (IBSS) networks by default (the purpose of this app is to have the android device generating an ad-hoc network). Therefore, the related definitions of isIBSS and frequency seem to be absent from the default version of android.
This app, according to its creators, is intended for use on Cyanogenmod which has been modified to support ad-hoc networks and does have these definitions (see this review).
Therefore my line of thought was that I had to use a modified version of the android SDK based on cyanogenmod that would have these definitions added in order for me to compile the program. However, as far as I can tell, no such thing exists.
Is my line of thought here correct, and does anyone have any solutions to offer for this problem? Please bear in mind I only have a basic understanding of Java and have never tried to compile an android app before.
Details: I have reinstalled eclipse 3 times, updated it & the ADT and DDMS, too.
I have found out that when I create a new android project the scr file is nearly empty. In each Activity there is only one java file and the rest is missing. I have attached a screenshot from the Maste/Detail flow activity so that you see where the problem is.
If you can help me please leave a response.
This is not a bug - it might generate additional files
depending on what starting activity you choose e.g. login activity it requires additional logic for working with Google+, however most will contain all the logic for a specific activity in a single source file, the source code included in the source files will often be minimal to make sure the activity works without the developer having to manually implement things they might otherwise not know about e.g. the fragment activity.
You might want to try out android studio instead if you are not dependent on eclipse as android seems to be moving towards using it and gradle.
(I do use android studios and am currently working on android apps and even though it's in beta it has not given me any problems)
This is a reported bug. Refer to https://code.google.com/p/android/issues/detail?id=72571
To solve the problem, look for ftl files in the tools\templates\activities subfolder of the SDK. In the files found, change <#if appCompat> to <#if appCompat?has_content>, and ${appCompat?string('Fragment','')} to ${(appCompat?has_content)?string('Fragment','')}.
I have written an application in eclipse for android and its working fine !!
I would like to send ios Rim and windows build using code name one Is it possible ? or do i have to write the whole code from scratch as a New Codename one project?
I tried directly sending my application using code name send android build but i got error.
Error log
[javac] C:\Documents and Settings\0mkar\My Documents\Downloads\Compressed\android\android\src\com\android\Log_SC.java:3: error: cannot find symbol
[javac] import java.io.BufferedWriter;
[javac] ^
[javac] symbol: class BufferedWriter
Full Error log
http://www.mediafire.com/?evb4ex8lg8054ja
Yes but you will need to adapt your code to use Codename One features only and need to rewrite your UI/networking code. E.g. BufferedWriter isn't supported however all streams are buffered so you don't need to buffer anything and the Writer/OutputStreamWriter are supported. This requires some effort, I don't want to discount that but its still way easier than porting to all these platforms manually.
The reasoning behind this is to maximize portability, the larger the API the more bugs and the larger the resulting applications would be when shipped on a platform that doesn't have a compatible VM (e.g. iOS or Windows Phone). It also slows down build times (more class lookups etc.).
The nice thing is that we try to help when you get stuck and if something important is missing its really easy to add both yourself (the project is open source and got a lot of contributions from 3rd parties) and by asking us.
Several random customers get this exception every time I update my Android app. I've narrowed it down to two reasons, both related to using the jni.
The *.so library is deleted when the app is upgraded.
The *.so library is not upgraded when the app is upgraded, and the old version still remains.
The device reports do not signal that this issue is related to the OS version, memory, or anything rational. Rather than focus on why Android is having trouble upgrading the libraries, I'm hoping someone out there knows how to manually pull the libraries out of the app's APK and put them in the right directory when this error is encountered.
Seems like you probably have an ABI mismatch - or possibly a false ABI mismatch caused by an Android bug that people have been talking about, where a generic arm library may not be accepted when one of the specialized varieties is preferred.
As for your workaround... you cannot write to the lib/ directory of your app's installation, though you can put a library elsewhere if you use System.load() with a precise path/filename instead of loadLibrary() with just a library name. I don't think there's any official (as in future-proof) way to extract arbitrary contents from your apk, though it's fairly easy to do at present with the zipfile classes (with something perhaps such as Context.getPackageCodePath() to discover the location and installation-variable name of the apk)
Checking for the success of the library loading attempt and reporting information about the device if it fails might be as useful.
I'm trying to disassemble/deodex the ROM that came with my Samsung Galaxy S2 device.
I'm using baksmali, But cannot get two files to do so properly, Email.odex and MobilePrint.odex. Both of them want java classes that don't seem to be included with anything else on the ROM - javax.swing.abstracttable and java.awt.image.
Does anyone know if implementations for these classes are available for Android/DalvikVM?
Samsung must have used SOMETHING.
In some cases, classes can be referenced in the dex file that just don't exist. This typically only happens on "dead" code paths that never actually get executed.
To get around this issue, baksmali has a -I option, to ignore these errors. This option should only be used if you are 100% certain that the classes really don't exist on the device. If used incorrectly, the option can possibly cause issues when using the device