Copy link to clipboard
Copied
If I set my target SDK to marshmallow and request storage access in my manifest, it will not prompt the user to allow at run time. It will just fail to allow me to access the contents of the local storage. Application directory access is fine but not docs directory. I can change the target sdk back to lollipop but I think users are going to start expecting those granular permissions. Anyone have insight how to do this? I hope we don't need an ane for every permission now...
Copy link to clipboard
Copied
Thanks for the explanation! And please, don't feel obligated to work on this or anything.
I don't think my app makes the text fields--you can actually see a bit of my app's flash-level UI under the translucent textfield, so it's probably part of the activity. I'll play around with a simplified text case and perhaps try distriqt's implementation to see if they have the same bug. It does seem very weird.
Copy link to clipboard
Copied
Quick note-- the Distriqt Camera ANE, which I believe has pretty much the same hack, doesn't have the same textfield problem. Is it possible that it's part of the activity template you or using? I have no idea how these things are put together.
Copy link to clipboard
Copied
It shouldnt be. My activity is blank other than an invisible LinearLayout which I think a layout is required so I can make it be invisible. Below is the activity's XML and Java files used. I also looked at the ActionScript files and I dont even have an import of any of the flash.text.* package.
Does the dummy FLA I included in the ZIP do the same thing? If you want to send me some of your files related to the class that triggers the permission request, I can take a look at it. Also, does it do that on every device you have tested with Marshmallow?
request_permissions_activity.xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:theme="@android:style/Theme.Translucent"
style="@android:style/Theme.Translucent"
android:background="#00000000"
android:visibility="gone">
</LinearLayout>
RequestPermissionsActivity.java
package com.wadedwalker.nativeExtension.permissions;
import com.wadedwalker.nativeExtension.permissions.R;
import android.annotation.TargetApi;
import android.app.Activity;
import android.os.Build;
//import android.graphics.Color;
//import android.graphics.drawable.ColorDrawable;
import android.os.Bundle;
@TargetApi(23)
final public class RequestPermissionsActivity extends Activity {
@Override
final protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//setTheme(android.R.style.Theme_Translucent_NoTitleBar);
setContentView(R.layout.request_permissions_activity);
//setVisible(false);
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.GINGERBREAD_MR1) {
if (getActionBar() != null) {
getActionBar().hide();
}
}
//getWindow().setBackgroundDrawable(new ColorDrawable(Color.TRANSPARENT));
this.requestPermissions(getIntent().getExtras().getStringArray("permissions"), android.os.Process.myUid());
}
@Override
final public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
super.onRequestPermissionsResult(requestCode, permissions, grantResults);
String results = "";
for (int i = 0; i < permissions.length; i += 1) {
results += permissions + "=" + grantResults;
if (i < permissions.length-1) {
results += ",";
}
}
PermissionsManager.context.dispatchStatusEventAsync("onRequestPermissionsResult", results);
finish();
this.overridePendingTransition(0,0);
}
}
Copy link to clipboard
Copied
Hmm, you're right, sorry. I made an extremely simple 2-line test app, and there's no mystery textfield. I'll slowly add stuff back till I figure it out, will let you know. Thanks!
Copy link to clipboard
Copied
No worries. Im glad it was something easy.
Copy link to clipboard
Copied
Okay, found the issue. There's a symbol conflict or somesuch with the popular Dialog ANE by distriqt. When that ANE is packaged in the same application we get the text fields, when it's removed, we do not. I guess something is sharing the same name.
Copy link to clipboard
Copied
Just getting clarity, when the Dialog ANE by Distriqt is included in the same app as my ANE, you get the text fields or when you have both of the Distriqt ANEs, you get the text fields?
Copy link to clipboard
Copied
When your PermissionsManager ANE is included with Dialog, I get the textfields. Don't have to run init or instantiate Dialog; just bundling it into the APK is enough. This is on a clean project with just the minimum amount of code in it.
Copy link to clipboard
Copied
That is just fascinating. Since my code (Im fairly certain anyway) has a different package structure than Distriqt then I am wondering if it is the request_permissions_layout.xml file because that technically isnt bundled in a package structure but is in the "res" folder. Since my Activity doesn't get "shown" until you actually request a permission to be granted, I really wonder what is going on in the background to make those textfields appear for you. Best guess at the moment is to try and change the name of the xml layout file and see if that changes anything. Does your app.xml file have any other special includes in the <android><manifestAdditions> section besides the <uses-sdk> and <uses-permission> tags, like another <activity> tag or something else?
Copy link to clipboard
Copied
Nope, not in the toy project I made. I'm not using the hideANESymbols option, though I think that's something different anyway?
Is the layout.xml name something I can change? Or just you?
Thanks!
Copy link to clipboard
Copied
I am unfamiliar with the hideANESymbols option. The file name is something I have to change. If you look at line #20 of the code sample I included, it is telling that Activity to be rendered using the "R.layout.request_permissions_activity". That is referring to the request_permissions_activity.xml file. Will try changing that file name later tonight and uploading a new version with just that change to see if it makes a difference.
Copy link to clipboard
Copied
Updated ANE and documentation. Changed the layout XML file name, tweaked the PermissionGroups class documentation to mention which permissions each group contains, and added a "shouldCheckForPermissions()" method that basically just checks to see if the Android OS the app is running on is Marshmallow or higher and returns true if so.
• Have not updated the documentation with recommended SharedObject preference tracking of which permissions have been requested or not.
• Will probably try to include some different styles that can be used in future documentation when writing out the <activity> tag in the app.xml's <manifestAdditions> section.
I did some more research to try and get the Activity to be blank/invisible without having the style set in the manifest, but there are several bug/issue reports on Google's own Android bug tracker that people say you cannot change the background on an activity to be invisible through either the layout.xml file or programmatically, and that the only way is through the apps manifest.xml file where you are required to list/declare each Activity your app uses. So at the moment, if you want the popup to appear on top of your app and not have a black background, you must include the style within the <activity> tag.
Copy link to clipboard
Copied
Sadly, it didn't seem to fix the text overlay stuff. I PM'd you a link to the Dialog ANE in case you'd like to see the problem yourself. If it's out of scope, no worries, I can figure something out. Thanks much!
Also: the textfields in the simple test case have words on them: username, password. Very odd.
Copy link to clipboard
Copied
Okay, here's some more bizarre test results. I was trying to figure out why the text fields are labeled in my simplified test case, but not in my app. The answer is that there is more than one conflict.
A similar thing happens with Milkman Plugin's CoreMobile ANE. Two textfields, but unlabeled this time. Now Coremobile and Dialog do share a lot of functionality--they both allow for login/password modal popups, for example. But a bit crazy to think it's a three-way naming collision.
The problem doesn't occur with every ANE, for example distriqt's Camera ANE is fine.
Copy link to clipboard
Copied
Hello wadedwalker​,
I'm now trying to solve the same request permissions problem and found this discussion. Is your ANE open sourced? None of the Dropbox links is working now.
Thanks.
Copy link to clipboard
Copied
It is not open sourced, but here is a permanent link to my drive hosted version.
https://drive.google.com/uc?export=download&id=0B7xgY_s0TJQtOHdWamtNWFpaZTQ
Copy link to clipboard
Copied
Thanks wadedwalker​​, but I had some error while trying your ANE, but I managed to get own (basic) version, which is available here for anybody who will need it: GitHub - Oldes/ANEAmanitaAndroid-public at eclipse-permissions
Copy link to clipboard
Copied
So you are saying you encountered an issue with my ANE and instead of letting me know what said issue is so I can try to fix it, you are just going to steal my code and claim it as yours without giving me any credit? Seriously?
I looked at what you put on GitHub and a large portion of that is a direct copy and paste of my work with just package names being changed.
Copy link to clipboard
Copied
I have no problem with giving you credits - if you give me whatever you want to write anywhere. Yes, I used your (java code which I found in your ANE) as a base, but I don't agree that I'm stealing something and that it is pure cut and paste - you can provide your code so anybody can compare it.
Sorry, I don't remember what was exactly the error message as I had so many different issues on the road. But basically I was not able to pack even the simple test apk with just your extension.
Also you should understand that for such a basic and important thing like "permissions" I don't want to use code which I cannot control myself.
It is a shame that Adobe is not the one providing these solutions.
Copy link to clipboard
Copied
And if I was just "stealing" like you say, I would not mention you in my original stack overflow question: android - How to receive response from ActivityCompat.requestPermissions running in Adobe Native Ext... and could just use my ANE without releasing anything. I just wanted to help anybody who can came later into this issue and so keep AIR platform a little bit longer alive.
Copy link to clipboard
Copied
Fine, you want examples?
PermissionsRequestActivity.java
You changed the name to "PermissionsRequestActivity" from my "RequestPermissionsActivity"
Changed the package name
Turned a while loop into a "for" loop
Added a Log.d() output.
Other than that, that Java file is identical to mine and didn't even change the variable names.
PermissionsFunctions.java
Changed the name to "PermissionsFunctions" from "PermissionsManagerFunctions".
Looks like you removed two methods because you didnt seem to see a need for them.
The CheckPermission method was simply converted from my 1 line "return" call into a couple of variables and inline conditional return
The RequestPermissions method is at least 95% of what my code was after the two method deletions already mentioned. You converted any of the "getActivity()" calls into a variable reference and added an extra conditional statement checking for a null value.
Removed comments.
You even maintained my package structure of having a "functions" folder.
So yes, I would think that anyone would call that stealing. Especially since: 1) you didnt even initially give me credit for the all the work I put into it on behalf of others in this community who initially requested help in the matter, 2) changed the names of the class files and layout file by an insignificant amount just to be different, and 3) messaged me directly to inform me that my source files were included in the ANE. So the fact that you bothered to go through the effort to try and see if there was code left in the published ANE file seems very sketchy to me in the first place.
Copy link to clipboard
Copied
Ok... so I'm a thief, if you believe. Here is your credits:
Wadedwalker credits · Oldes/ANEAmanitaAndroid-public@e0310ff · GitHub
Let me know if you want to put some more info (email, webpage, whatever)... or do some refactoring. I could also post your original files for regular comparison, but because as I see your are not fun of sharing code, I will not do that without your permission.
Btw... you named the only 2 files in the project which are related to your code (if I don't count the activity layout xml).
Thanks anyway for your help in this thread.
PS: Again I repeat that I just wanted to help others (don't play some "mark this answer as correct" game) I could just use my code silently. If I would want to steal something, I would not post messages here and there, where you can see it.
Copy link to clipboard
Copied
Anyway.. I still cannot resist.. because you say... "Other than that, that Java file is identical to mine and didn't even change the variable names." I must post at least one comparison... here is CheckPermission function - the first is your version and how I modified it. Revisions · CheckPermission · GitHub
You really cannot say, that I just renamed something to hide your authorship. You are returning permissionCheck result, while I return if the permission is granted or not. PackageManager.PERMISSION_GRANTED is equal 0... so in your case if you put some nonsense as an input, you will receive 0 on AIR side, which could mean, that you have rights. Maybe for you it is just a detail, but for me such a details are important. I can name other, if you would like.
And btw... I found the implementation for my version in Google's ContextCompat.java source file, where is:
/**
* Determine whether <em>you</em> have been granted a particular permission.
*
* @param permission The name of the permission being checked.
*
* @return {@link android.content.pm.PackageManager#PERMISSION_GRANTED} if you have the
* permission, or {@link android.content.pm.PackageManager#PERMISSION_DENIED} if not.
*
* @see android.content.pm.PackageManager#checkPermission(String, String)
*/
public static int checkSelfPermission(@NonNull Context context, @NonNull String permission) {
if (permission == null) {
throw new IllegalArgumentException("permission is null");
}
return context.checkPermission(permission, android.os.Process.myPid(), Process.myUid());
}
Never mind, it does not make sense to continue... I'm really sorry what I did wrong. Next time I will take it more seriously.
Copy link to clipboard
Copied
You're trying to make light of you straight up copying my work and are now trying to justify it. First of all, in immediate response to your last message, my comment about the Java file being identical was in reference to the "PermissionsRequestActivity.java" file, which I clearly called out. I also clearly called at the differences you made in the CheckPermissions method. You changing it returning a boolean vs an int is irrelevant in this instance because I matched the Android API which at this point in time can only return two values, 0 for granted and -1 for denied, so it is functionally the same. And if you "put some nonsense as an input" as you stated, it would probably break. But my ANE, packaged with lots of documentation, is a full replication of the Android API in AS3 form.
To your previous comment of I only pointed out two files that are at least 90% of my code (less the two functions removed in the Functions class). Those two classes are the ones pivotal to the functionality of this ANE on the Java/Android side.
I also see how you are also trying to mock me in the changes to your GitHub listing saying, "This code was partially stolen from Wadedwalker as is explained here" just goes to show your immaturity. You got caught with your hand in the cookie jar, called out on it, and are now trying to defend it. Simple as that.
Copy link to clipboard
Copied
Sorry, but I would call everybody to be stupid or incompetent, if they would use some foreign ANE and not checking what is inside!
Anyway... the Activity file is opensourced by yourself in this post:
Re: File system permissions in Android Marshmallow
And if you check my code, I don't use the result on AS3 side at all.. .it could simply return just "done" or whatever else.
Never mind.... call me like you like. I'm really ending this silly discussion.
Have a nice day.
Find more inspiration, events, and resources on the new Adobe Community
Explore Now