3

I am customizing an NXP based Android 10 BSP on an iMX8 platform and I'm trying to make a custom swipe up bottom sheet that's global to the OS like the status/notifications bar on a swipe down gesture.

I've followed this thread here but customized the swipe up layout to have a list of applications available on the OS (basically a launcher within an app).
While this feature works great within my app, I actually want that slide up layout to be global so that I can launch applications no matter which card/application I'm currently on.

How would I go about doing this since this feature is limited to my main app? Would it be possible to add this to SystemUI?

Rick Sanchez
  • 4,528
  • 2
  • 27
  • 53
Tony
  • 33
  • 4

1 Answers1

2

Yes technically, you can do something like the existing NotificationBar that you can drag from the top of the screen. In your case you'd do from the bottom.

The logic for NotificationPanelView is in SystemUI package.

But beware, the existing logic there is a bit spaghetti code, so it could take a while to understand in order to add your own panel.

Another option for you would be to have your panel as an overlay view on top of everything ( drawn from a background service from your app ). See this answer for some initial guidance.

You'd show at first a transparent view, that receives all inputs. If you detect the gesture, you 'move up' the sheet from the bottom, otherwise you pass the input to apps below.

Note that this:

  • Would mean your service needs to be a foreground service, so its not killed.
  • If your app is killed from Settings, the BottomSheet will go away as well.
  • You cannot show this over the Settings app ( intentional Android limitation)

To recap:
The SystemUI solution would be better long term, less limitations... but more difficult to develop initially.
The App overlay solution is easy to implement, but has several limitations which can be a dealbreaker.

Rick Sanchez
  • 4,528
  • 2
  • 27
  • 53
  • 2
    Great answer. I do agree, the best way is to work with SystemUI. Rick, what universe are you traveling now? Also worth checking Xiaomi AOSP implementations, they have a nice approach on that under the hood. – Yurii Tsap Nov 25 '20 at 20:56
  • 1
    Still in C137 – Rick Sanchez Nov 25 '20 at 21:38
  • Thanks this was very helpful in pointing me in the right direction. How would you recommend porting SystemUI into an IDE like Android Studio to begin understanding this codebase better? I've noticed some suggestions to decompile the SystemUI.apk but was wondering if there was a better or easier way. – Tony Nov 30 '20 at 15:24
  • You open AOSP up in IntelliJ and code in that: https://stackoverflow.com/questions/59682479/which-ide-should-i-use-for-aosp-android/59697705#59697705 – Rick Sanchez Nov 30 '20 at 16:14
  • 1
    @RickSanchez You weren't kidding when you said the existing logic was a bit spaghetti code lol. I'm confused how to get started with outside tools with my custom panel such as Dagger. Is this really necessary for what I want to do? Also I've noticed that the resource id's for existing items like the notification panel are generated by the aapt tool. Is this handled automatically when I build from the command line? – Tony Dec 07 '20 at 20:48
  • Hahahah, told you. I once had to modify it to add some custom things on lock screen and took me almost a week to implement. It's a mess – Rick Sanchez Dec 07 '20 at 21:21
  • 1
    You can add outside libs, though I haven't used Dagger in AOSP built app myself, seems there are ways https://stackoverflow.com/a/50830290/3801327. ResIDs are autogenerated by the build even on normal android apps with AS/gradle, so it's the same here. – Rick Sanchez Dec 07 '20 at 21:22
  • @RickSanchez thanks! Why does Android disallow overlay panels over the Settings app? I've noticed that the Xiaomi Mi A3 was able to work around this issue with their launcher implementation it seems – Tony Dec 07 '20 at 22:26
  • If they didn't, an app could just show some ad over all the screen, and you'd have no way to stop it or kill it ( since you couldn't force-stop from Settings ). Not allowing overlays over Settings solves this problem. This ultimately has to do with the type of window and what are it's "priorities". See https://developer.android.com/reference/android/Manifest.permission#SYSTEM_ALERT_WINDOW , this tells you that the permission allows for TYPE_APPLICATION_OVERLAY type. If your app is a system app you can acutally use some more "prioritiezed" type like TYPE_PHONE – Rick Sanchez Dec 07 '20 at 22:57
  • @RickSanchez oh I see! My plan is to make my app a system app which will replace the QuickStep launcher. If I prioritize my app as TYPE_PHONE, I could override that restriction right? – Tony Dec 07 '20 at 23:20
  • I think it's that type, but don't rember for sure. If that doesn't work, try the other types from the list https://developer.android.com/reference/android/view/WindowManager.LayoutParams#TYPE_PHONE – Rick Sanchez Dec 07 '20 at 23:34
  • @RickSanchez It allows me to pass in certain priorities like TYPE_SYSTEM_DIALOG and TYPE_STATUS_BAR_PANEL, but fails to run since I don't have permissions. Is there a way I could test these permissions before installing the app as a system app? – Tony Dec 08 '20 at 23:34
  • Dont think so. Sign your app with platform certificate, and if still doesn't give you the needed permission, make it use the system user ( android.uid.system ), which is the permission level Settings has. https://stackoverflow.com/questions/17222535/create-system-application – Rick Sanchez Dec 09 '20 at 08:15