神刀安全网

Blended Android tidbits

This time I don’t have a full article about one specific topic but rather few useful tips. These are not really bound together, you don’t need to read from the top to the bottom but you can skip to what interests you most.

Permissions – Application lifecycle consideration

I don’t want to explain once again how the new (still?) permission system works on Android because the official documentation does a great job in this regard and there are plenty of blog posts and tutorials around.

I just want to put the focus on one aspect, remembering the users can grant or deny permissions while your application is running.

So I have created a project with Android Studio with just one empty Activity and I have declared a dangerous permission in the manifest, just to have it in the Settings screen of the application. Then I have overridden almost all the lifecycle methods for my Activity and the Application class (so I have implemented a custom one too).

Now the first test, granting a permission:start the application, put it in background, open to application Permissions setting screen, grant my permission and open again the application from the Recents view. This is the log:

com.fasteque.permissionsapplication.PermissionsApplication: attachBaseContext com.fasteque.permissionsapplication.PermissionsApplication: onCreate com.fasteque.permissionsapplication.MainActivity: onCreate com.fasteque.permissionsapplication.MainActivity: onStart com.fasteque.permissionsapplication.MainActivity: onResume com.fasteque.permissionsapplication.MainActivity: onResumeFragments com.fasteque.permissionsapplication.MainActivity: onPause com.fasteque.permissionsapplication.MainActivity: onSaveInstanceState com.fasteque.permissionsapplication.MainActivity: onStop com.fasteque.permissionsapplication.MainActivity: onRestart com.fasteque.permissionsapplication.MainActivity: onStart com.fasteque.permissionsapplication.MainActivity: onResume com.fasteque.permissionsapplication.MainActivity: onResumeFragments

Now the second test, revoking a permission:start the application, put it in background, open to the application Permissions setting screen, revoke my permission and open again the application from the Recents view. This is the log:

com.fasteque.permissionsapplication.PermissionsApplication: attachBaseContext com.fasteque.permissionsapplication.PermissionsApplication: onCreate com.fasteque.permissionsapplication.MainActivity: onCreate com.fasteque.permissionsapplication.MainActivity: onStart com.fasteque.permissionsapplication.MainActivity: onResume com.fasteque.permissionsapplication.MainActivity: onResumeFragments com.fasteque.permissionsapplication.MainActivity: onPause com.fasteque.permissionsapplication.MainActivity: onSaveInstanceState com.fasteque.permissionsapplication.MainActivity: onStop com.fasteque.permissionsapplication.PermissionsApplication: attachBaseContext com.fasteque.permissionsapplication.PermissionsApplication: onCreate com.fasteque.permissionsapplication.MainActivity: onCreate com.fasteque.permissionsapplication.MainActivity: onStart com.fasteque.permissionsapplication.MainActivity: onRestoreInstanceState com.fasteque.permissionsapplication.MainActivity: onResume com.fasteque.permissionsapplication.MainActivity: onResumeFragments

As you can clearly see, if you grant a permission while your application is in background, but still alive, when you resume it, nothing special happens, you get the usual lifecycle, with the Activity started and resumed again.

But in the second case, when you revoke a permission, methods to create both the Application and the Activity are called.

This has been tested on a Samsung S7 (6.0.1) and a Nexus 6 (N Preview2 – NPC91K).

Permissions – Grant them all for testing

This is a quick tip useful when you manually install an application, because the standard adb installation command does not grant any of the requested dangerous permission by default. And this is completely fine, in the end that’s the same exact behaviour you get when installing an application from Google Play Store.

But let’s say you’re in the development phase, you have to delete and re-install your application several times and you don’t want all the time to deal with runtime permissions. So simply add a parameter, -g , to your command:

adb install -g YOUR_APPLICATION.apk

Files directory symbolic link

We all know that getFilesDir() returns the path of the directory holding application files. Starting from API Level 23  getFilesDir() returns /data/user/0 instead of /data/data/ like in the past.

But this is just a symbolic link to /data/data/ , so the data of any application is still actually saved to /data/data/ as usual. I guess the reason for this change is related to Android for Work : in the past I’ve indeed noticed that the system, in order to manage two different profiles, personal and work, creates two “users”, 0 (personal) and 10 (work). In this way, Android can separate personal and work applications, so you can install the same application for both profiles, of course with data and notifications separation.

You don’t have to worry about it unless your application deals with canonical paths, because a canonical path is an absolute path with symbolic links and references to “.” or “..” resolved.

Shrinking debug builds

Starting from version 2.0.0-beta7/2.1.0-alpha3 (2016/3/19)  of the Android Gradle plugin, there’s a new (experimental) built-in shrinker available, which can be used instead of ProGuard.

You can enable it in this way:

android {     buildTypes {         debug {             minifyEnabled true             useProguard false             proguardFiles getDefaultProguardFile('proguard-android.txt')         }     } }

Please note this removes dead code only, but it doesn’t optmize or obfuscate your code.

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Blended Android tidbits

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址