I've run into the FileUriExposedException stuff where you try to send a file:/// Uri to another app (in this case the camera), and I should be using a FileProvider instead (causes a crash on api 24 Nougat).
In our app, we generate a File using Context's getExternalFilesDir(String) method:
context.getExternalFilesDir("attachments");
The FileProvider documentation leads me to believe I should be using external-files-path in my paths.xml if I want the functionality to be the same as is now.
<?xml version="1.0" encoding="utf-8"?>
<paths>
<external-files-path
name="attachments"
path="attachments/" />
</paths>
But after googling some more, I found a few things that make me think there's issues with FileProvider, or at least FileProvider's documentation...
https://code.google.com/p/android/issues/detail?id=61170
#commonsWare
answer and comment https://stackoverflow.com/a/30276915/921988
The README of this active library that says it adds support for external-files-dir https://github.com/commonsguy/cwac-provider#metadata-elements
Also, I'm getting java.lang.IllegalArgumentException: Failed to find configured root that contains ... right now, but that might be caused by something else.
So
Am I right in thinking I should use external-files-path if I want to match how my app currently works?
Is the documentation/FileProvider really broken/incorrect and I should use something like cwac-provider instead?
UPDATE
For completeness, as #CommonsWare recommended below, using the 24.2.0 version of support-v4 is working for me.
Am I right in thinking I should use external-files-path if I want to match how my app currently works?
Yes. Though do note that getExternalFilesDir() does not officially support "attachments" as a parameter, so do not be surprised if your app breaks someday.
Is the documentation/FileProvider really broken/incorrect
Well, I see the code for external-files-path support in the sources JAR for 24.2.0 of the new support-core-utils artifact. support-v4, as of 24.2.0, has been subdivided into a series of separate artifacts, and FileProvider lives in support-core-utils.
So, try using 24.2.0 of support-v4 (or support-core-utils if you do not need all of support-v4).
I had similar scenario of sharing a private file to the camera to upload full quality image without putting a permission to WRITE_EXTERNAL_STORAGE.
I was able to make it work by using the as follows
<?xml version="1.0" encoding="utf-8"?>
<paths>
<external-path
name="my_images"
path="Android/data/com.santhoshn.appprivateimageupload/files/Pictures" />
</paths>
Here is the working sample app https://github.com/santbob/AppPrivateImageUpload
Related
I keep getting the following error when uploading an app to google play:..
You uploaded an APK or android App Bundle which specifies an actions schema document in its manifest, but action schemas are not yet allowed. If you are part of a beta program, you need to have your developer account whitelisted.
I have applied to become whitelisted, but when I filled out the form my app did not meet the criteria for an specific 'type' (it is not a financial program etc.)
Most of the articles I have read say this relates to meta data content which some say can be deleted... my app however, will not work without the metadata content.
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="#xml/file_paths" />
and here is the resource file_paths
<paths xmlns:android="http://schemas.android.com/apk/res/android">
<external-path
name="ConfinedSpace_images"
path="Android/data/com.mynamehere.confinedspacemanagement/files/Pictures" />
</paths> ```
Does anyone know of a workaround?
It seems there is no getting around the google whitelist problem. I also found that my manifest had two areas of meta-data in it. The file system seems to be fine, but the following code seems to be where my problem is originating
<meta-data
android:name="com.google.android.actions"
android:resource="#xml/file_paths" />
I have deleted the meta data above and things still seems to work. I am curious though... where did the code come from, and more importantly.... what does it do? I openly admit I am still somewhat of a copy and paste programmer.
My problem now is that my camera will not work in my app???? any advice?
Update Dec 2/2019 ----- Camera now works fine. My problem was that the xml file_path resource wasn't changed... it was still trying to save to com.example.-----------
I have android project where I am using lots of layout as common resources in other activity layouts. for example, I have a layout for headers , which I include in 4 activity layouts for visual consistency. Since I have lots of common layouts created, my layout folder is very cluttered. I was looking for a way to package them separately. What I wanted to do is to create another sub-folder inside the layout folder and put all the shared resources there like :
under res folder
layout(folder)
--activity_home.xml
--other_activity.xml
--common ( folder)
--header_layout.xml
--other_shared_layouts.xml
From this link in SO, I found that its not supported in android which was answered 4 years ago. It mentions that, gradle can resolve this issue by proper mergings, but I would prefer other options if there are any.
I was wondering if there are any other ways to handle this scenario? I am just trying to organize the layouts file so that they don't clutter in one folder.
Is gradle the ONLY way to go ?
This is my SDK details if that matters .
<uses-sdk
android:minSdkVersion="15"
android:targetSdkVersion="21" />
Thanks in advance for any kind of input.
This is still unsupported. Android studio's Android scoping looks slightly better.
I have an app "Gurbani Ujagar" which views about 3000 HTMl pages using WebView. I have received many emails about adding an move to SD Card option. I have no idea what that means, how that makes a difference, and how I can add this option?
This is actually incredibly easy to do! First, make sure your target API level is 8 or higher. If it is, you can simply include this code in your manifest:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:installLocation="preferExternal"
... >
For more information, check out this android developer page.
Is there any way to refactor the name of a class file as well as all the references to that name in the Android project?
For example, if I Refactor > Rename the file CustomerListFragment.java , the following reference in Android resource files still needs to be changed manually.
<fragment android:name="my.package.CustomerListFragment"
android:id="#+id/item_list"
android:layout_width="400dp"
android:layout_height="match_parent"
/>
I think Visual Studio does this kind of refactoring automatically, is there any equivalent in Eclipse(Android)?
Yes and no, it's actually listed on their roadmap as:
Better refactoring support
Believe it or not, the refactoring/renaming support has actually gotten better over the last couple of weeks. Until very recently, it was still making mistakes when replacing class names and package names in the Manifest file (whenever some Activity file name was being refactored/renamed). But lately, I haven't been getting these errors, and I'm very happy that this isn't a manual step I have to do anymore.
You can also check out their bug tracker at:
http://b.android.com and star the issue if you really want to get notified when this exact test case gets taken care of.
For my personal purposes I'd like to parse comments in Android Manifest file. In these comments there can be tags with attributes and values that I want to extract. It is similar to tag in html files that is usually commented because some browsers does not support this tag. So I want to implement similar things in android manifest.
I know that in Android manifest file is parsed using SAXParser. Moreover, I think I should use LexicalHandler for this purposes but I've never faced before with this functionality and I want to know how to do this. Code snippets and any help will be highly appreciated!
I'm entirely sure that you cannot parse the raw XML Manifest, because like everything that is in the res folder (except res/raw), the manifest is compiled and stored in a binary format, so the comments are removed.
Maybe you can play with xmlns and capture the manifest parsing... But I doubt it, the Manifest is interpreted by the package manager, and I don't think that you can have access to it.
The solution (from your feedbacks):
The requested feature is impossible, because during the compilation all comments from AndroidManifest file are removed.
You can check this in the following way:
Create a simple app project (Hello World) and add comments in your AndroidManifest file.
Compile project and export an .apk file (signed or unsigned).
Using tools like apktool or similar extract your apk file.
Check the result in AndroidManifest.xml - there are no comments.
You should try to find other way.
I don't think it is possible as the AndroidManifest is not available as a classpath resource. The only way I can think of is to actually make a copy of the AndroidManifest.xml into your source files and have it built as a compiled object using an ant target
Then you just access it like a normal XML file using the XML APIs.
I hate to be that guy, but you should probably maintain your custom XML in /assets/ and not overload the manifest.xml file.