Develop Reference

Getting ProtoBuf.ProtoException using OsmSharp in Xamarin Android

I am trying to test a sample project called Android.Routing.Offline from OsmSharp.Samples in Github.
After two taps on the screen (the first one gets just the GeoCoordinate) I get a ProtoBuf.ProtoException in the Router.cs
private static IBasicRouterDataSource<CHEdgeData> _graph;
public static void Initialize()
{
var routingSerializer = new CHEdgeDataDataSourceSerializer();
_graph = routingSerializer.Deserialize(
Assembly.GetExecutingAssembly().GetManifestResourceStream(#"Android.Routing.Offline.kempen-big.contracted.mobile.routing"));
}
public static Route Calculate(GeoCoordinate from, GeoCoordinate to)
{
try
{
lock(_graph)
{
var router = Router.CreateCHFrom(_graph, new CHRouter(), new OsmRoutingInterpreter());
// The exception happens here below
var fromResolved = router.Resolve(Vehicle.Car, from);
var toResolved = router.Resolve(Vehicle.Car, to);
if(fromResolved != null && toResolved !=null)
{
return router.Calculate(Vehicle.Car, fromResolved, toResolved);
}
}
}
catch(Exception ex)
{
OsmSharp.Logging.Log.TraceEvent("Router", OsmSharp.Logging.TraceEventType.Critical, "Unhandled exception occured: {0}", ex.ToString());
}
return null;
}
And the exception:
> {ProtoBuf.ProtoException: Invalid wire-type; this usually means you
> have over-written a file without truncating or setting the length; see
> http://stackoverflow.com/q/2152978/23354 at
> ProtoBuf.ProtoReader.ReadSingle () ...
I didnt overwrite the file (kempen-big.contracted.mobile.routing) just added it as a linked file in the project. Any ideas how I can solve this issue?

Well, the first thing to try is to check that the contents of the Stream you are reading (via GetManifestResourceStream) contains exactly the contents you are expecting, and not some wrapper or otherwise-corrupt mess. If you have some checksum algorithm you can run: great! Checking just the .Length would be a great start. Otherwise, you could cheat (just for the purposes of validating the contents) by getting the hex:
using (var ms = new MemoryStream())
{
stream.CopyTo(ms);
string hex = BitConverter.ToString(
ms.GetBuffer(), 0, (int)ms.Length);
// dump this string, and compare it to the same output run on the
// oringal file; they should be identical
}
Note that this duplicates the contents in-memory, purely so we can get a byte[] (oversized) to get the hex from - it isn't intended for "real" code, but until you are sure that the contents are correct, all other bets are off. I strongly suspect that you'll find that the contents are not identical to the contents in the original file. Note that I'm also implicitly assuming that the original file works fine in terms of deserialization. If the original file doesn't work: again, all bets are off.

Accessing layer contents in Android-surfaceflinger

I am reading the layer contents to check whether its the same content as that rendered by the app on-screen. I am reading the contents before they are being composited by SurfaceFlinger. Here is the block of code in HWCLayerVersion1::setAcquireFenceFd() in HWComposer.cpp, to dump the layer content/pixels to a raw-file.
getLayer()->acquireFenceFd = fenceFd;
private_handle_t *hnd = (private_handle_t*)getLayer()->handle; // the handle of the layer
/*code for checking layer contents*/
if(private_handle_t::validate(getLayer()->handle)==0){
ALOGD("beta: we are gonna read a valid buffer-> %08x", intptr_t(getLayer()->handle));
char filename[64];
memset(filename, 0, 64);
int name = clock();
sprintf(filename, "/data/dump.%08x.raw", intptr_t(getLayer()->handle));
if(getLayer()->acquireFenceFd >= 0){
int ret = sync_wait(getLayer()->acquireFenceFd, -1);
if(ret < 0){
ALOGD("beta: sync_wait failed");
} else{
FILE *file = fopen(filename,"w+");
//ALOGD("beta: writing pixels");
fwrite((void*)hnd->base, hnd->size, 1, file);
close(getLayer()->acquireFenceFd);
//getLayer()->acquireFenceFd = -1;
}
} else {
ALOGD("beta: fencefd not valid");
}
}
When I am reading the pixels using IrfanView with the appropriate attributes, the image only faintly resembles the actual content, but the colors are all smudged. What is the reason behind this? Is the buffer being rendered while I am reading the content? I'm totally new to AOSP, and any help would be appreciated.

If your host (in case its an emulator) or device supports graphic acceleration , then yes, the buffer you are reading is not fully rendered yet.
Latest Android releases support a sync mechanism which means that buffers (layers) can be acquired by the SurfaceFlinger while they are being rendered. They are protected by a fencing mechanism which ensures that a buffer that's not fully rendered will not be displayed.

How to get the size of the data received via EXTRA_STREAM in an application handling the action send intent?

When another application is sending a file to my app, I get a Uri via the intent.getExtras().get(EXTRA_STREAM) property. I can then get the bytes of the file using an inputstream : new BufferedInputStream(activity.getContentResolver().openInputStream(uri));
Everything's OK and working so far. Now I'd like to show some kind of progress to my user, but I'm not sure of how to get the total number of bytes of the file without reading the stream completely beforehand (which would defeat the whole purpose of the progress bar) ...
I tried ParcelFileDescriptor fileDesc = activity.getContentResolver().openFileDescriptor(uri, "r"); but this only works with uris of type file://....
For example If I receive a file from Skydrive I get a content://.. Uri, as in : content://com.microsoft.skydrive.content.external/external_property/10C32CC94ECB90C4!155/Sunset.480p.mp4
On such Uri I get (unsurprisingly) a "FileNotFoundException : Not a whole file" exception.
Any sure fire way to get the total size of the stream of data I will get ?

Even though InputStream.available() is (almost) never a recommended way of getting file size, it might be a viable solution in your case.
The content is already available locally. A server is not involved. So, the following should return the exact file size:
try {
InputStream inputStream = getContentResolver().openInputStream(uri);
Log.i("TEST", "File Size: " + inputStream.available());
} catch (FileNotFoundException fnfe) {
fnfe.printStackTrace();
} catch (IOException ioe) {
ioe.printStackTrace();
}
I tested this with SkyDrive and Dropbox. The file sizes returned were correct.

There is no general solution for getting the size of a stream, other than reading the entire stream. This is easily proven: One could create a web server that, for some URL, generates a random stream of text that is terminated at a random time. (In fact, I'm sure such URLs exist, whether by design or not :-) In such a case, the size of the stream isn't known until the last byte has been generated, never mind received.
So, the stream size, if it is sent by the server at all, has to be sent in an application-specific manner.
I've never worked with SkyDrive, but a google search for its API turned up this link, which has the following example for Android Java apps:
public void readFile() {
String fileId = "file.a6b2a7e8f2515e5e.A6B2A7E8F2515E5E!141";
client.getAsync(fileId, new LiveOperationListener() {
public void onError(LiveOperationException exception, LiveOperation operation) {
resultTextView.setText("Error reading file: " + exception.getMessage());
}
public void onComplete(LiveOperation operation) {
JSONObject result = operation.getResult();
String text = "File info:" +
"\nID = " + result.optString("id") +
"\nName = " + result.optString("name");
resultTextView.setText(text);
}
});
}
Based on other examples on that page, I would guess that something like result.optString("size") (or maybe result.optInt("size") ?) would give you the size of the file.

Obfuscate JPG by bit-toggle - reading performance on Android

Abstract:
reading images from file
with toggled bits to make unusable for preview tools
cant use encryption, to much power needed
can I either optimize the code below, or is there a better approach
Longer description:
I am trying to improve my code, maybe you got some ideas or improvements for the following situation. Please be aware that I neither try to beat the CIA, nor care much if somebody "brakes" the encryption.
The background is simple: My app loads a bunch of images from a server into a folder on the SD card. I do NOT want the images to be simple JPG files, because in this case the media indexer would list them in the library, and a user could simply copy the whole folder to his harddrive.
The obvious way to go is encryption. But a full blown AES or other encryption does not make sense, for two reasons: I would have to store the passkey in the app, so anyone could get the key with some effort anyway. And the price for decrypting images on the fly is way too high (we are talking about e.g. a gallery with 30 200kB pictures).
So I decided to toggle some bits in the image. This makes the format unreadable for image tools (or previews), but is pretty easy undone when reading the images. For "encrypting" I use some C# tool, the "decrypt" lines are the following ones:
public class CustomInputStream extends InputStream {
private String _fileName;
private BufferedInputStream _stream;
public CustomInputStream(String fileName) {
_fileName = fileName;
}
public void Open() throws IOException {
int len = (int) new File(_fileName).length();
_stream = new BufferedInputStream(new FileInputStream(_fileName), len);
}
#Override
public int read() throws IOException {
int value = _stream.read() ^ (1 << 7);
return value;
}
#Override
public void close() throws IOException {
_stream.close();
}
}
I tried overwriting the other methods (read with more then one byte) too, but this kills the BitmapFactory - not sure why, maybe I did something wrong. Here is the code for the image bitmap creation:
Bitmap bitmap = null;
try {
InputStream i = CryptoProvider.GetInstance().GetDecoderStream(path);
bitmap = BitmapFactory.decodeStream(i);
i.close();
} catch (Exception e1) {
_logger.Error("Cant load image " + path + " ERROR " + e1);
}
if (bitmap == null) {
_logger.Error("Image is NULL for path " + path);
}
return bitmap;
Do you have any feedback on the chosen approach? Any way to optimize it, or a completely different approach for Android devices?

You could try XORing the bytestream with the output of a fast PRNG. Just use a different seed for each file and you're done.
note: As already noted in the question, such methods are trivial to bypass.

Is there any way to tell what folder a drawable resource was inflated from?

Does anyone know of a way to tell which folder Android system will resolve to when I request a particular drawable from the Resources (drawable-long vs. drawable-notlong, for example)? I want to make sure it's loading resources the way I would expect it to (for instance, to make sure the Tattoo is really ldpi and not mdpi since it's right on the borderline).
I could always print out the intrinsic size of the drawable after I fetch it from Resources, and check that against the various image sizes I have, but that's kind of a pain. Plus, my company allows its clients to skin their app before it's released, so after it's been skinned I won't be able to rely on that method.
I tried using Resources.getName(resId) but that doesn't give the folder name, and as far as I know you can get a AssetFileDescriptor for the resource but you can't get an actual filename.
UPDATE:
Since asking this question I have discovered that you can access many of the resource qualifier names through the Configuration and DisplayMetrics classes (both accessible via getResources()). DisplayMetrics can give you the ldpi/mdpi/hdpi designation, and Configuration can give you small/normal/large screen size, long/notlong aspect ratio, locale, mobile network codes, and other hardware information. However, this still does not positively confirm that you are getting the resources you expect if you have a complicated resource set. It also does not protect you from bugs that report the incorrect values, like the Motorola Droid bug where the DisplayMetrics reports the wrong xdpi and ydpi (it reports 96dpi where the real value is more like 265dpi! Terrible bug.).

A different approach would be to use two different images, with the same name, red in one resource folder blue in the other. When it inflates, you'll be able to see which one it is coming from.
If you really want to go crazy, make an image saying "ldpi" or "xhdpi" etc for each folder and when you start your project, you can note which ones came up for each device you wanted explicit testing for.
From Mark Allison, same idea but the values directory with strings that contains the name of the bucket it's in - it's less effort than creating images!

I know, you write, that you can go through all resources and compare sizes with the bitmap size. But I don't know, if you thought it same way as I did, so this may help you or someone else.
So this is the way I did it. At first I load sizes (in bytes) for all drawable images.
String defType = "drawable";
String drawableDirPrefix = "res/drawable";
SparseArray<SparseArray<String>> resourceDirs = new SparseArray<SparseArray<String>>();
ZipInputStream apk = null;
try {
apk = new ZipInputStream(new FileInputStream(getPackageResourcePath()));
ZipEntry entry = null;
while ((entry = apk.getNextEntry()) != null) {
String resourcePath = entry.getName();
if (resourcePath.startsWith(drawableDirPrefix)) {
int firstSlashPos = resourcePath.indexOf('/');
int lastSlashPos = resourcePath.lastIndexOf('/');
int dotPos = resourcePath.lastIndexOf('.');
String resourceDir = resourcePath.substring(firstSlashPos + 1, lastSlashPos);
String resourceName = resourcePath.substring(lastSlashPos + 1, dotPos);
int resourceId = getResources().getIdentifier(resourceName, defType, getPackageName());
int resourceSize = (int) entry.getSize();
SparseArray<String> resourceInfo = resourceDirs.get(resourceId);
if (resourceInfo == null) {
resourceInfo = new SparseArray<String>();
resourceInfo.append(resourceSize, resourceDir);
resourceDirs.append(resourceId, resourceInfo);
} else {
resourceInfo.append(resourceSize, resourceDir);
}
}
}
} catch (IOException e) {
Log.e("tag", "Error", e);
} finally {
if (apk != null) {
try {
apk.close();
} catch (IOException e) {
Log.e("tag", "Error", e);
}
}
}
Then, when I want to know the folder, I can compare the bitmap size to loaded sizes.
InputStream bitmapStream = null;
try {
int bitmapId = R.drawable.icon;
bitmapStream = getResources().openRawResource(bitmapId);
int bitmapSize = bitmapStream.available();
String bitmapDir = resourceDirs.get(bitmapId).get(bitmapSize);
Log.i("tag", bitmapDir);
} catch (Exception e) {
Log.e("tag", "Error", e);
} finally {
if (bitmapStream != null) {
try {
bitmapStream.close();
} catch (IOException e) {
Log.e("tag", "Error", e);
}
}
}
Well, this will work only if the images have different sizes. Or you can compare other things, like width, height, etc.
May be it is not, what you are looking for, but at least it satisfied my needs.