I am using WallpaperManager.setBitmap to set the device's wallpaper.
I have the permissions set correctly. It works fine for 99% of the times however sometimes it simply sets the default instead of mine.
There is no exception (I have try-catch and I have logs. No exception. No crashes. Nothing).
The method is void so there is also nothing to check after calling it.
It is just being called and instead of setting the given bitmap - it sets the default.
http://developer.android.com/reference/android/app/WallpaperManager.html#setBitmap(android.graphics.Bitmap)
Here's the code:
WallpaperManager.getInstance(context).setBitmap(bitmap);
The bitmap is not recycled (I am checking for it before reaching this line of code).
Any ideas what can go wrong or what alternative to use?
Using a resource is not an option as the bitmap is dynamically generated in memory.
The generated bitmap size, in my device's case (Nexus 5) is always the same: 2160x1920, regardless the successful or failure results.
Also - it is a PNG.
I will meanwhile run some tests with setStream instead:
http://developer.android.com/reference/android/app/WallpaperManager.html#setStream(java.io.InputStream)
Hopefully it works better ...
Try this method instead, to directly reference the bitmap as a drawable resource:
WallpaperManager.getInstance(context).setResource(R.drawable.myImageId);
The method call assumes your bitmap is in a drawable resource folder (and not e.g. assets).
See API docs for more details.
Related
I have an app which has to create Sprite-instances on the fly based on data contained in byte arrays (PNGs and JPGs). The following code is used to create the sprites:
Texture2D texture = new Texture2D(2, 2, TextureFormat.RGBA32,false,false);
texture.LoadImage(data);
Vector2 pivot = new Vector2(0.5f, 0.5f);
Rect tRect = new Rect(0, 0, texture.width, texture.height);
return Sprite.Create(texture, tRect, pivot);
This works fine, however, depending on the device and the size of the images, after a random number of images, the app freezes and then will be shut down by the OS. Its always another image, which fails. Also, the data source is irrelevant.
Looking into the logs of the app via adb shows nothing. If I write to the debug log, I can see, that the last statement which gets called is texture.LoadImage. However, there is no exception or another information about the error. Catching the exception does also not work.
The error does not occur in the editor. The error occurs on the android devices (2) in development build and in production build.
Searching the web, I found the below entry, which states the very same problem, but no solution has been posted (they circled around the www-part, however the problem is not with that):
https://forum.unity.com/threads/android-crash-when-using-multiple-www.483941/
UPDATE
One interesting finding is, that if I set the markNonReadable-Parameter of the texture.LoadImage() method to true, the error occurs less frequently, but still is there.
texture.LoadImage(data,true);
Textures are not garbage collected. So if you create a texture using new Texture then you need to destroy the texture with Destroy(texture) when you no longer need it. I believe Sprite object also needs to be destroyed.
In your case, textures that were loaded stayed in memory until Android OS closed your app because of memory pressure.
UnloadUnusedAssets() should also destroy all the textures and sprites that are no longer referenced, but it takes a lot of time (about 1 second), so it only makes sense to call that when changing scenes.
I'm using the popular ZXing project to enable barcode scanning on my Android application.
I want to manually set the width and height of my viewfinder, so I used the following:
intent.putExtra("SCAN_WIDTH", 400);
intent.putExtra("SCAN_HEIGHT", 300);
Before sending my intent. However, the app crashes due to a NullPointerException at line 279 in CameraManager.java. I did some debugging and it looks like the screenResolution member of configManager is never initialized. I debugged some more, to find that surfaceCreated() is not called in time (this is supposed to be done through a Callback). At least, that is what it seems like to me, since surfaceCreated() in CaptureActivity.java is responsible for initializing those members of configManager. I did some searching on here and Google but it doesn't seem like people use those intent extras SCAN_WIDTH and SCAN_HEIGHT. They are manually setting the MIN and MAX width/height values within the ZXing code, which I am trying to avoid. Any help would be appreciated.
The scanner works fine when I am not setting those width/height values via intent.
EDIT: After updating my version of the ZXing library, this is no longer an issue. It also fixed the front camera issue I was having with the 2012 Nexus 7.
screenResolution is definitely set, in initFromCameraParameters. It happens when the driver opens. It's OK if surfaceCreated happens a bit later since the onResume method registers a callback to initialize the camera after the surface is created, if it's not already available.
onResume calls setManualFramingRect even if it's not initialized, but, in that case it just saves the request in requestedFramingRectWidth and requestedFramingRectHeight and sets it later.
I think this case is handled correctly, but as ever I can't be 100% sure there's not an oversight. Maybe you can say more about where you think the problem is given this info.
I have some code that works fine in iOs, but which results in completely messed up images when on Android. I have found a partial workaround (not call some code), but it hints something is terrible wrong:
// some bitmap object buffer for mainthread only
R.BitmapRef := FPersistentBitmapBuffer;
// this TImage now contains the original wrongly sized bitmap
ImageBackground.Bitmap.Assign(R.BitmapRef);
// calculated somewhere
TmpNewWidth := 500;
TmpNewHeight := 500;
// draw the bitmap resized to wanted size
R.BitmapRef.Width := Round(TmpNewWidth);
R.BitmapRef.Height := Round(TmpNewHeight);
R.BitmapRef.Canvas.BeginScene();
R.BitmapRef.Canvas.DrawBitmap(ImageBackground.Bitmap, RectF(0,0,ImageBackground.Bitmap.Width,ImageBackground.Bitmap.Height), RectF(0,0,TmpNewWidth,TmpNewHeight), 1);
R.BitmapRef.Canvas.EndScene();
// assign it back to the image
ImageBackground.Bitmap.Assign(R.BitmapRef);
// THIS code causes the image shown in TImageBackground to look completely garbled ... which would indicate something is shareing memory/reference somewhere somehow... There is more odd behavior like debugger unhooking (it seems) if mouse in Delphi debugger hovers over ImageBackground.Bitmap - no error is reported
R.BitmapRef.Clear(TAlphaColorRec.White);
As can be seen, it the last line that messes it up. In some tests it has seemed to be enough to remove he line, but not in others. This is my best lead/description/example of the problem.
Here is an example of how a garbled image looks like. Since they look garbled the same way each time I run the app, I suspect it must be somehow relate to the image, but there is not any visual similarity.
My question is what could be wrong? I am testing the Delphi XE7 trial, so I can not access the source. It worked flawlessly on iOS using XE4 and XE7, but with Android something is going on. I am thinking it could possibly be some bitmap data that is sharing a reference... Does anyone have any ideas on how to test this theory / possible workarounds?
This looks plainly wrong. I'd suggest that you fill a bugreport at http://quality.embarcadero.com
Try using CopyFromBitmap instead of the "Assign". This will create a unique copy of the image. You'll also get a new unique image if you call MyBitmap.Map(TMapAccess.Write, MyBitmapData); followed by MyBitmap.UnMap(MyBitmapData);.
I have the follow code to get the screenshot
View screen = getWindow().getDecorView();
screen.setDrawingCacheEnabled(true);
screen.setDrawingCacheQuality(View.DRAWING_CACHE_QUALITY_HIGH);
screen.buildDrawingCache();
Bitmap bitmap = screen.getDrawingCache();
The code is in onOptionsItemSelected in UI thread.
It runs fine when I test it manually. However, when I run the app with monkey, bitmap is nullI am not sure if it always null in monkey mode or just occasionally since monkey's randomness.
Any ideas that why monkey could behave differently? I do not want to blindly add a null pointer checker in later code.
Thanks
you should use buildDrawingCache(true) because buildDrawingCache() is same as buildDrawingCache(false).Make sure to copy bitmap to another one before using getDrawingCache() like below.
Bitmap bt=Bitmap.createBitmap(screen.getDrawingCache());
because its copy our bitmap before recycle() if you call setDrawingCacheEnabled(false).
So I am using the Android camera to take pictures within an Android app. About 90% of my users have no issues, but the other 10% get a picture that returns pure black or a weird jumbling of pixels.
Has anyone else seen this behavior? or have any ideas why it happens?
Examples:
Black:
Jumbled:
I've had similar problems like this.
The problem in short is: Missing data.
It occurs to a Bitmap/Stream if the datastream was interrupted for too long or it is accidentally no more available.
Another example where it may occur: Downloading and uploading images.
If the user disables all of a sudden Wifi/mobile network no more data can be transmitted.
You end up in a splattered image.
The image will appear/view okay(where okay means black/splattered, it's still viewable!) but is invalid internally (missing or corrupted information).
If it's not too critical you can try to move all the data into a Bitmap object (BitmapFactory.decode*) and test if the returned Bitmap is null. If yes the data possibly is corrupted.
This is just solving the consequences of the problem, as you can guess.
The better way would be to take the problem on the foot:
Ensure a good connection to your data source (Large enough, stout buffer).
Try to avoid unneccesary casts (e.g. from char to int)
Use the correct type of buffers (Either Reader/Writer for character streams or InputStream/OutputStream for byte streams).
From android 4.0 they put hardwareAcceleration set to true as default in the manifest. Hardwareaccelerated canvas does not support Pictures and you will get a black screen...
Please also check that whether you use BitmapFactory.Options object for generating the bitmap or not. Because few methods of this object also makes the bitmap corrupted.