IssueTracker

Confirm the issue.
OS: Windows 8.1, Ubuntu

Confirmed.

Version of Android Studio (available in the about box): 0.5.0
OS version: OpenSuse 13.1 x64
Java JRE/JDK version: 1.7.0_51
OpenJDK Runtime Environment (IcedTea 2.4.4) (suse-24.13.5-x86_64)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

I'm looking into this issue today.

Just delete line resources.srcDirs = ['src']
It solved the problem for me

Version of Android Studio (available in the about box): 0.5.0
OS version: Gentoo x64
Java JRE/JDK version: 1.7.0_51-b13

Confirmed problem and solution in #5 reply too.

@gabin Thx for the workaround. It's working for me.

I found the problem!!!!

The issue is that 'src' is both Java source and Java resource folder. Studio first marks it as Java source (good thing) and .java files are seen as Java classes, and right after that, the same folder is marked as a resource one (I'm talking in IDEA terms). The fix is to make Studio do the opposite. Working on it.

Fix confirmed. It works.

What surprises me is that this is not new in 0.5.0. We had this bug in previous versions!

BTW, the issue with gradle file editor (marking "main" as warning) is a separate issue.

Fix pending: https://android-review.googlesource.com/84343

This will be in 0.5.1.

Great news, thanks.
Will be waiting for 0.5.1

Confirmed. #5 work for me too

Fix has been merged. Studio 0.5.1 will have this change.

first just want to say thanks so much for ShevT's work on building the 12.1CM for my device. From his example I was able to build my own 12.1CM which helped me understand what I think might be causing this issue



"starting in API level 19, this permission is not required to read/write files in your application-specific directories returned by getExternalFilesDir(String) and getExternalCacheDir()".

While using an app I could not save the config file.  I contacted the developer and he was very cool and said there were issues with "custom Rom's" and could not save anything to the app-specific directory.  I looked into this further, and saw this stack trace:


"main@3610" prio=5 waiting
  java.lang.Thread.State: WAITING
      at libcore.io.Posix.open(Posix.java:-1)
      at libcore.io.BlockGuardOs.open(BlockGuardOs.java:186)
      at libcore.io.IoBridge.open(IoBridge.java:442)
      at java.io.RandomAccessFile.<init>(RandomAccessFile.java:117)
      at a.a.a.d.g.<init>(g.java:74)
      at a.a.a.i.a.a(a.java:617)
      at a.a.a.i.a.a(a.java:2283)
      at a.a.a.a.c.b(c.java:1901)
      at a.a.a.a.c.b(c.java:1620)
      at com.moletag.galaxy.s4.remote.a.a(a.java:904)
      at com.moletag.galaxy.s4.remote.ab.onClick(ab.java:133)
      at com.android.internal.app.AlertController$ButtonHandler.handleMessage(AlertController.java:162)
      at android.os.Handler.dispatchMessage(Handler.java:102)
      at android.os.Looper.loop(Looper.java:135)
      at android.app.ActivityThread.main(ActivityThread.java:5289)
      at java.lang.reflect.Method.invoke(Method.java:-1)
      at java.lang.reflect.Method.invoke(Method.java:372)
      at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:904)
      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:699)

      This send me on a tail-spin through the system (This is my first debugging attempt).. as you can see the trace ends at libcore.io.Posix.open which is one of native libs or hooks into the kernel.  Since I had no answers I decided to get the source build my own 12.1 (based entirely on all SHEVT's hard work) and see if I could work it out.  I built the image.. and started digging but no matter how far I went down everything seemed just fine.  I guess I should have listened to that, eventually I decided to take a look at an sTrace and compare against a stock image 12.1 in this case running on an emulator.  So here is the trace from a stock 12.t that has no permissions issues.. (sdk_phone_x86_64_end 5.1 LKY45 1737565 test-keys):


newfstatat(AT_FDCWD, "/storage", {st_mode=S_IFDIR|0550, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated", {st_mode=S_IFDIR|0751, st_size=80, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated/0", {st_mode=S_IFDIR|0771, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated/0/Android", {st_mode=S_IFDIR|0771, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated/0/Android/data", {st_mode=S_IFDIR|0771, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated/0/Android/data/com.moletag.galaxy.s4.remote", {st_mode=S_IFDIR|0770, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated/0/Android/data/com.moletag.galaxy.s4.remote/files", {st_mode=S_IFDIR|0770, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0

OK here was a trace from 12.1 custom build:

newfstatat(AT_FDCWD, "/storage", {st_mode=S_IFDIR|0550, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/storage/emulated", 0xbe981a80, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)
newfstatat(AT_FDCWD, "/storage/emulated/0", 0xbe981a80, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)
newfstatat(AT_FDCWD, "/storage/emulated/0/Android", 0xbe981a80, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)
newfstatat(AT_FDCWD, "/storage/emulated/0/Android/data", 0xbe981a80, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)
newfstatat(AT_FDCWD, "/storage/emulated/0/Android/data/com.moletag.galaxy.s4.remote", 0xbe981a80, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)
newfstatat(AT_FDCWD, "/storage/emulated/0/Android/data/com.moletag.galaxy.s4.remote/files", 0xbe981a80, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)

as you can see.. it fails right at /storage/emulated with permission denied.  I realized I had no idea about the android file system so I spent a month drawing a picture.. which I can post here if you want.. it helped me come the file system on a 12.1 stock versus a 12.1 custom .. well 12.1 samsung to be precise.  I found a difference.. /storage on stock has the following
for 12.1 stock:
 /storage [directory r-x r-x --X]  context: rootfs uid: system gid: sdcard_r
 for 12.1 CM12.1
 /storage [directory r-x r-x ---]  contrext: rootfs uid: system gid: sdcard_r

as you can see the difference is small (no world-executable)  as you know the executable bit on directories is rewired to traverse (enter the directory).  SO if we look at the statement from google, it says "WRITE_EXTERNAL_STORAGE and READ_EXTERNAL_STORAGE" are no longer required IF the app just wanted to access its app-specific directory.  Well how does the app do that?  From the strace you can see apps are like users.. they start at "/" and try to get to the target, in this case the target directory is returned by the API  getExternalFilesDirs() and the env variable included in the platform specific init file for NEXUS it is
 export EXTERNAL_STORAGE /storage/sdcard and for my device its
 export EXTERNAL_STORAGE /storage/emulated/legacy
  Each platform might have varying filesystem designs, and store the actual data in different places, that is up to them.. but both SAMSUNG and google use a path that includes /storage in trying access the FUSE mounted file systems.  And as you also know the ANDROID permissions READ_EXTERNAL_STORAGE simply grant the app the linux group permission sdcard_r (the WRITE_EXTERNAL_PERMISSION gives both the sdcard_r and sdcard_rw).  SO now we can see that google used the filesystem permissions to implement the new policy of not requiring those specific permissions because stock images changed? or perhaps always had a world-executable path to the data.  However SAMSUNG does not.  ON my device if I am to remove the android permissions from the manifest, the app during install has the following :
  and for example an app which is not granted those permissions:
uid=10104(u0_a104) gid=10104(u0_a104) groups=9997(everybody),50104(all_a104), context=u:r:untrusted_app:s0

Notice as it tries to traverse to its app-specific directory the kernel denies it right at storage.. and rightfully so as the app is not uid=system and it is NOT in the sdcard_r group. However the app, with this same set of permissions can access its data on the NEXUS, because the executable bit is set on /storage. anyone can traverse that directory.. As we know google implemented app-owned directories down at the actual location, to prevent anyone from poking around.

SO in short, this permission setting for whatever reason is missing on many custom ROMS.. I don't know the history of CM, or when MOD's diverged or indeed if this change was intentional.  I'm merely pointing out that in the current state, it does not function per the android statement.

In closing I did test this by remounting root as rw and making the CHMOD 551 as root..   and no longer am I getting any permissions denied.  I have noticed this bug report awhile back (open since 2014)  https://code.google.com/p/android/issues/detail?id=81357 which  Thanks again for SHEVT's work, without it I would never have been able to work out the big picture and arrive at a solution (hopefully) that will prove beneficial to all.. I just love my device!

mikel

Any clue when an update will be pushed out?

we release roughly weekly.

My build.gradle file doesn't have "resources.srcDirs" defined at all but I'm still getting this error.

sourceSets {
    main {
        manifest.srcFile 'src/main/AndroidManifest.xml'
        java.srcDirs = ['src/main/java']
        res.srcDirs = ['src/main/res']
        assets.srcDirs = ['src/main/assets']
    }
}

Daniel, what is the error that you are getting? Can you please share some more details?

BTW, I tried the snippet you provided with Studio (after fix applied) and it worked fine.

Hovering over sourceSets{main{}} shown above in Android Studio gives me tooltip error 'main' in 'build' cannot be applied to (groovy.lang.Closure<java.util.ArrayList>)'.

Builds are now yielding errors about xml files being invalid but compiling from the cli works perfect. This was all working perfect before 0.5.0

I updated to 0.5.1 and still have the tooltip error.

## Here is my build.gradle file (Android library):

apply plugin: 'android-library'

android {
    compileSdkVersion 14
    buildToolsVersion "19.0.3"

    buildTypes {
        /*
            Publish all variants (debug and release here) of the library so they are available to other project
            http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication
         */
        publishNonDefault true
    }

    sourceSets {
        main {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            java.srcDirs = [
                    'src/main/java',
                    'src/main/deps/email/src',
                    'src/main/deps/jsr305/src'
            ]
        }
    }
}

## Android Studio tooltip displays on the main block
'main' in 'build' cannot be applied to '(groovy.lang.Closure<java.util.ArrayList>)'
This inspection reports assignments with incompatible types

I can build successfully on 0.5.1 but I still get the same error tooltip as #22