We Keep Coding

Huawei specific OS flavour creating weird files in my files folder

Basically, I need to save some files in my app. For that, I use the directory returned by getFilesDir() method (like here).
This works fine, but on some devices (I know at least two), files named hw_cached_resid.list or aware_learning_data appear in this folder. Why is this happening and how to avoid this?
UPDATE: Google search revealed nothing, but GutHub code search luckily found one reference of hw_cached_resid.list. Turns out, it's from some (decompiled!) Huawei firmware, more specifically - com.huawei.iaware app.
Huawei's documentation says the Huawei Mate 9 uses something called iAware System, a machine learning platform that learns your usage and preempt changes between apps as well as pre-loading frequently used apps.
(quote from here)

It looks like it's a bug with built-in software of Huawei phones (some temporary files don't get deleted).
Thus, the only way to fix it (without contacting Huawei) - just to check if those files exist and delete them.

Errors on building an android project: "isIBSS/frequency cannot be resolved or is not a field"

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.

Using HTC's Bluetooth LE library in Xamarin, is this possible?

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!

How to find file path of a Java API class?

In particular - the Applet.class. How could I find where it locally resides? I have tried the following, but I get an exception:
System.out.println(JApplet.class.getProtectionDomain().getCodeSource().getLocation().getPath());
It is of course somewhere in Program Files/Java/jdk_7_xx/ but I have had quite a look around and searched online and cannot find the answer. I have always wondered where specific classes reside on the system.
Note: If you want some more detail (not necessary to read below this):
What I specifically want to do is edit the Applet.class and point my Eclipse to a new JRE System Library that contains the edited Applet.class. In theory this sounds plausible, yet in practice I am unsure.
This is needed so I can test legacy code which keeps making calls to super methods - I have tried many frameworks/approaches and tried multiple possible solutions that have been posted on stack overflow and other online resources - none work.

Found the JApplet.class in C:\Program Files (x86)\Java\jdk1.7.0_25\jre\lib\rt.jar
Made a back-up of jdk1.7.0.25 on my desktop and put it in a folder Desktop\BACKUP\jdk1.7.0.25
Unzipped it (rt.jar), decompiled Applet.class with jad, changed some methods and even added a new one, recompiled it, rezipped it, replaced the old rt.jar with the new one, made a new eclipse project and made it use the JRE in Desktop\BACKUP\jdk1.7.0.25 and it worked perfectly.

..do you know how I can find the specific path of the Applet.class?
For your own PC? Sure. For the PC of a client of your applet? No.
In fact, Oracle (or was it Sun?) eventually decided it was not the business of an app. launched within the Java Plug-In (e.g. applets or JWS apps), to know where the classes were cached. Not even it that app. was fully trusted.
I'm assuming its in a jar somewhere?
Don't assume. It is set in the Java Control Panel, which defaults to 'no compression'.

Some customers get a java.lang.UnsatisfiedLinkError when upgrading my Android app. How do I fix this?

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.