I am using Xamarin and my app supports API 9+, but when I add this flag:
ScreenOrientation = ScreenOrientation.SensorPortrait
It gives me this error:
Error: String types not allowed (at 'screenOrientation' with value 'sensorPortait').
But when I change it to SensorLandscape, it works.
I've read, that there is some kind of a but, but setting it to SensorPortait gives me error even sooner (int the IDE)
Related
I've been trying to print with Brother Print SDK 3.5.1 on Android 8.1.0. I keep getting ERROR_WRONG_LABEL.
This is the code I use
void printPdf() {
// Specify printer
final Printer printer = new Printer();
PrinterInfo settings = printer.getPrinterInfo();
settings.printerModel = PrinterInfo.Model.QL_810W;
settings.port = PrinterInfo.Port.NET;
settings.ipAddress = "192.168.1.73";
settings.workPath = "storage/emulated/0/Download/";
// Print Settings
settings.labelNameIndex = LabelInfo.QL700.W62RB.ordinal();
settings.printMode = PrinterInfo.PrintMode.FIT_TO_PAGE;
settings.orientation = PrinterInfo.Orientation.PORTRAIT;
settings.isAutoCut = true;
printer.setPrinterInfo(settings);
// Connect, then print
new Thread(new Runnable() {
#Override
public void run() {
if (printer.startCommunication()) {
PrinterStatus result = printer.printPdfFile("/storage/emulated/0/Download/hello world red.pdf", 1);
if (result.errorCode != PrinterInfo.ErrorCode.ERROR_NONE) {
Log.d("TAG", "ERROR - " + result.errorCode);
}
printer.endCommunication();
}
}
}).start();
}
My printer model is QL-810W and I use the black and red W62 roll.
I've tried the Sample Application, where setting W62RB in labelNameIndex prints fine.
Changing the roll for different one with different width didn't help.
I've also tried iterating over numbers 0 to 50 and using them as labelNameIndex.
Based on this thread, I thought that the issue may be in specifying the workPath attribute. Setting workPath to getContext().getCacheDir().getPath() results in ERROR_OUT_OF_MEMORY instead of ERROR_WRONG_LABEL. Not specifying workPath and adding <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> to AndroidManifest.xml results in ERROR_WRONG_LABEL
EDIT
I've modified the Brother Sample app and uploaded it to GitHub. The app now launches Activity_PrintPdf.java by default where I inserted my printing code with hardcoded values at the beginning of onCreate method - this works fine and prints the PDF file as expected.
Then I created a new Empty Activity project in Android Studio, copy pasted the library, added the imports to build.gradle and copy pasted the permissions into AndroidManifest.xml. Then I copy pasted the printing code at the beginning of onCreate method in MainActivity.java. Running the app results in ERROR_WRONG_LABEL.
This is the modified working example app and this is the one that results in the error. I want to use the code as native module that I call from my React Native app, so it's important that I manage to set up the printing code from scratch rather than modifying the existing example app.
EDIT 2
I've inspected the library with a debugger: when executing printer.setPrinterInfo(mPrinterInfo) the library internally calls private boolean createWorkPath(String dirPath) of Printer object. On return from this method, the debugger shows Source code doesn't match the bytecode and seems to forget the created directory. This also internally sets mResult.errorCode = ErrorCode.ERROR_WORKPATH_NOT_SET. However, instead of rising any error here the code just silently proceeds, which later results in ERROR_WRONG_LABEL when trying to print. Running the same code snipper in the modified Sample app works fine.
I'd be grateful if you could help or suggest what to try next.
Thank you!
I've now fixed the issue, which was that the Brother library silently failed to create a temporarily folder and instead of reporting an error, it continued and failed later to read the label information. Based on this thread, it is now required to specify runtime file read and write permissions as opposed to the compile-time ones in AndroidManifest.xml.
Adding
ActivityCompat.requestPermissions(this,
new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE},1);
at the beginning of onCreate before the printing code fixed the issue.
In Android 6.0/API23 and earlier, the following used to work:
String settingEnabled = android.provider.Settings.Secure.getString(this.getContentResolver(), "enabled_notification_listeners");
In Android 7.0 Nougat/API24 this seems to be no longer supported, because the code above returns null.
It actually was never mentioned here: https://developer.android.com/reference/android/provider/Settings.Secure.html
How do we check if our app has notification access in Android 7.0 Nougat API24?
Edit: It seems that actually that after you first gained the access in the settings, the code above returns the correct state. But not on the initial request after installation.
Use this:
Set<String> packageNames = NotificationManagerCompat.getEnabledListenerPackages (context);
I'm using android Log.isLoggable api in order to determine whether my custom log tag is on and should I log. (I'm setting property using setprop log.tag. on the device).
As far as Docs says, and as I'm familiar with older version, it should return true if the log level in the property is equal or high than the one I'm checking in my code.
This works fine for Lollipop and below (api 22) it's seems that something was changed in Marshmallow, as I encounter inconsistency and buggy behavior, playing with the values of the tag will result sometimes with the wrong value returned from isLogabble(), for instance a concrete scenario I did a check in code :
boolean shouldLog = Log.isLoggable("mytag", Log.DEBUG);
Log.d("debug", "shouldLog = " + shouldLog);
I set log.tag.mytag value to some arbitrary string
launch my app, and see the isLoggable = false, that's OK
then I change log.tag.mytag to VERBOSE
launch my app, isLoggable still false , that's not OK! should be true now
same scenario is not reproducible at Lollipop and didn't encounter any other misbehaviors.
Any suggestions, do I miss something here?
I'm issuing a simple command to my mediaControllerCompat:
controller.adjustVolume(-1, 0);
Yet my app FCs with...
java.lang.IllegalArgumentException: Bad direction 3
at android.os.Parcel.readException(Parcel.java:1469)
at android.os.Parcel.readException(Parcel.java:1419)
at android.media.IAudioService$Stub$Proxy.adjustStreamVolume(IAudioService.java:1097)
at android.media.AudioManager.adjustStreamVolume(AudioManager.java:952)
at android.support.v4.media.session.MediaSessionCompat$MediaSessionImplBase.adjustVolume(MediaSessionCompat.java:1376)
at android.support.v4.media.session.MediaSessionCompat$MediaSessionImplBase.access$1700(MediaSessionCompat.java:963)
at android.support.v4.media.session.MediaSessionCompat$MediaSessionImplBase$MediaSessionStub.adjustVolume(MediaSessionCompat.java:1602)
at android.support.v4.media.session.MediaControllerCompat$MediaControllerImplBase.adjustVolume(MediaControllerCompat.java:969)
at android.support.v4.media.session.MediaControllerCompat.adjustVolume(MediaControllerCompat.java:252)
at pl.qus.xenoamp.NewMainActivity.onKeyDown(NewMainActivity.java:1149)
MainActivity being the caller of mentioned line... What is WRONG?!
This was an internal bug in the Android Support Library has been fixed as of version 23.1.0.
Previous Answer
This is a bug in the support library that affects pre-API 21 devices that use local playback (i.e., have not called setPlaybackToRemote()) - the order of parameters sent to AudioManager.adjustStreamVolume() as per the source code is incorrect - hence why the direction appearing as 3 - the value for STREAM_MUSIC.
You may be able to temporarily work around it by always calling setPlaybackToRemote() on pre-API 21 devices, passing in a VolumeProviderCompat that does correctly call AudioManager.adjustStreamVolume(), but you must also handle the other methods of VolumeProviderCompat such as retrieving the max volume (via getStreamMaxVolume()) and current volume (via getStreamVolume()) as well as setting the volume (via setStreamVolume()).
I came across the same error using API 23 (not the Support Library) and running on an M device. I solved it by listening for the error and calling an API 1 method in its place, when necessary.
try {
...
} catch (IllegalArgumentException e) {
audioManager.setStreamVolume(STREAM, VOLUME, FLAGS);
}
Since the Compat interface calls the internal methods for system volume control, you could also instantiate an instance AudioManager if you are not directly declaring one already.
I recently switched to using Android ndk-r9 and am having some difficulty with my app that seems to be related to compiler optimization. I have the following function:
int GetTouchPos(GTouchEvents * pEvents, GPointF * pPos, int * pButton = 0)
{
int count = 0;
GTouchEvent * pEvent;
if (pEvents->GetCount(&count) == GResult_Ok)
{
GDebugLog((GS("GetTouchPos: count = %d"), count));
if (pEvents->GetEvent(0, &pEvent) == GResult_Ok)
{
pEvent->GetTapPos(pPos);
if (pButton)
{
pEvent->GetButton(pButton);
}
pEvent->Release();
}
}
return(count);
}
If I build my project and run it, the call to GDebugLog formats and logs the value of the variable 'count'. When I do this, 'count' is 1 and my app works correctly. However if I comment out the GDebugLog line (and make NO other changes), when I run my app, it no longer works. In the function GTouchEvents::GetCount, I also am logging what it is returning and the value is always correctly '1'. Also, I log the return from the call to the function above (i.e. GetTouchPos). When the GDebugLog line is present, the logged return value is the correct value '1'. However when I comment out the GDebugLog call, the logged return value is a seemingly random number, which looks suspiciously like an uninitialized variable.
Note that this all works with our without the GDebugLog line when I was using r8b. Also note that if I turn optimization off, this code works perfectly using r9 whether the debugging line is present or not. Also note that this behavior only presents itself when compiling for the ARM processor. The version I build for x86 works without problem.
Am I doing something questionable here that is causing the optimizer to generate incorrect code?
Can anyone shed some light on what might be happening?
Thanks.