Related
For my Xposed Module Play Store Chagenlog an update was released yesterday, this added a GUI as wel as some options. There have been quite a few reports about settings preferences not being applied. After some debugging, I found out that this XSharedPreferences simply doesn't have any entries and thus always returns the default values. I'm 100% sure the options are set (the preferences screen shows them correct and you can see them in the .xml) and the right file is being loaded. There are no errors in the Xposed Log or in the logcat.
I've found a workaround (only tested by me), unchecking and re-checking an option and then the preferences are read correctly. All my modules (actually most of all Xposed Modules) use this way to load an user's preferences, I have absolutely no clue what's causing this behaviour.
The source code is on GitHub, links to relevant files:
PlayStoreChangelog.java
SettingsActivity.java
SettingsFragment.java
settings.xml
For debugging purposes, I've added a snippet to dump the preferences beneath initializing XSharedPreferences. This says it loads the right file, the file exists but it contains no entries (size 0). So when trying to get values (getString, getBoolean etc), it only returns the default values.
Java:
sharedPreferences = new XSharedPreferences(BuildConfig.APPLICATION_ID);
XposedBridge.log(LOG_TAG + sharedPreferences.getFile().getAbsolutePath() + " exists: " + sharedPreferences.getFile().exists());
XposedBridge.log(LOG_TAG + " ---PREFS: " + sharedPreferences.getAll().size() + "---");
Map<String, ?> sortedKeys = new TreeMap<String, Object>(sharedPreferences.getAll());
for (Map.Entry<String, ?> entry : sortedKeys.entrySet()) {
XposedBridge.log(LOG_TAG + entry.getKey() + "=" + entry.getValue().toString());
}
Summary
The app uses a PreferenceFragment to set the preferences and XSharedPreferences to load them. The changes are written to the .xml file and shown in the GUI. The XSharedPreferences instance remains empty and does not contain any entries, thus it always returns the default value. I don't get why it doesn't work, I don't even get why the 'workaround' does work.
I'd really appreciate any help, I'm stuck on this one. No idea what causes it and whether it's a but in my code or something else.
I hope I gave enough information. Thanks in advance.
I'm really stuck on this one, I haven't got a clue what causes this. Maybe @rovo89, @MohammadAG, @GermainZ or @defim, you guys are the most experienced Xposed developers out here. Thanks in advance!
Could something like `sharedPreferences.makeWorldReadable();` (probably needs to be in initZygote) solve your issue? I can't personally think of any reason this might happen except a permission issue.
(Also make sure you're using the latest Xposed Bridge API. I remember there were some commits related to XSharedPreferences, although I can't remember what they were exactly and can't check right now.)
Permission problem sounds reasonable. PSC has for its xml file only set 660, so world readable is mission. After changing it by command line Play Store starts as expected. But i've to say that i use in no app the makeWorldReadable(), Xposed should do it by itself: http://forum.xda-developers.com/showpost.php?p=41976845&postcount=1586 But I also dont use settings fragment, which could cause it...
GermainZ said:
Could something like `sharedPreferences.makeWorldReadable();` (probably needs to be in initZygote) solve your issue? I can't personally think of any reason this might happen except a permission issue.
(Also make sure you're using the latest Xposed Bridge API. I remember there were some commits related to XSharedPreferences, although I can't remember what they were exactly and can't check right now.)
Click to expand...
Click to collapse
defim said:
Permission problem sounds reasonable. PSC has for its xml file only set 660, so world readable is mission. After changing it by command line Play Store starts as expected. But i've to say that i use in no app the makeWorldReadable(), Xposed should do it by itself: http://forum.xda-developers.com/showpost.php?p=41976845&postcount=1586 But I also dont use settings fragment, which could cause it...
Click to expand...
Click to collapse
First of al, both thanks you for your response, it's highly appreciated.
I've been testing with permissions, it indeed looks like a permission problem, because makeWorldReadable() solved it. I use the following line the SettingsFragment to make it World Readable, which has always worked, even though Context.MODE_WORLD_READABLE is officially deprecated because if security reasons:
Java:
getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE);
It creates a file with 660 permissions, with makeWorldReadable in initZygote it sets it to 664. This is my initZygote:
Java:
@Override
public void initZygote(StartupParam startupParam) throws Throwable {
sharedPreferences = new XSharedPreferences(BuildConfig.APPLICATION_ID);
XposedBridge.log(LOG_TAG + "Readable before: " + sharedPreferences.getFile().canRead());
sharedPreferences.makeWorldReadable();
XposedBridge.log(LOG_TAG + "Readable after: " + sharedPreferences.getFile().canRead());
}
The weird thing is, both readable before and after return true, which indicates it has the permission to read the file before makeWorldReadable(). But... it doesn't work without it
In the end, I created a snippet in SettingsFragment to solve it where the problem arises, instead of makeWorldReadable():
Code:
File sharedPrefsDir = new File(getActivity().getFilesDir(), "../shared_prefs");
File sharedPrefsFile = new File(sharedPrefsDir, getPreferenceManager().getSharedPreferencesName() + ".xml");
if (sharedPrefsFile.exists()) {
sharedPrefsFile.setReadable(true, false);
}
This still needs setSharedPreferencesMode(Context.MODE_WORLD_READABLE), otherwise the permissions will be reset to 660 when a preference changes, now they stay 664. So basically al it does it make it readable for others in addition to the setSharedPreferenceMode().
Thanks again for your replies, it really helped. I still think it's weird, especially since File.canRead() returns true, while it obviously can't read it. I hope it'll help others in the future.
I think I use the deprecated SettingsActivity for this reason. I can override getSharedPreferences so it always returns a world readable file, this avoids the permissions resetting when a preference changes.
Sent from my HTC One_M8 using Tapatalk
MohammadAG said:
I think I use the deprecated SettingsActivity for this reason. I can override getSharedPreferences so it always returns a world readable file, this avoids the permissions resetting when a preference changes.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Thanks for your response, just checked out one of your modules, saw you were using getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE); too. (and indeed SettingsActivity). This has always been sufficient for me using PreferenceFragment. To be sure it's world readable I now manually set the permissions on onPause as a workaround. Still weird because it has always worked flawless for me.
P1nGu1n_ said:
Thanks for your response, just checked out one of your modules, saw you were using getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE); too. (and indeed SettingsActivity). This has always been sufficient for me using PreferenceFragment. To be sure it's world readable I now manually set the permissions on onPause as a workaround. Still weird because it has always worked flawless for me.
Click to expand...
Click to collapse
Yeah, I also override getSharedPreferences in PreferenceActivity, that allows it to stay world readable.
Sent from my HTC One_M8 using Tapatalk
Sam code works for me in XInstaller. Try check it out, it is open source.
Be aware that using XSharedPreferences will probably lead to problems on Lollipop caused by more stringent SELinux rules.
M66B said:
Be aware that using XSharedPreferences will probably lead to problems on Lollipop caused by more stringent SELinux rules.
Click to expand...
Click to collapse
Good point, but it's too early to say. I'll wait for Xposed to be compatible (hope it will), than I'll look into what changes it'll require. That's something almost every Xposed developer will face ;p
Sent from my phone, please forgive any tpyos.
Yes, I think also Xposed should then handle with LOL XResources properly
Breaking XSharedPreferences means that *almost* every module is not going to work on Lollipop.
I also migrated my project to use PreferenceFragment and getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE) pretty much does nothing. After I change any setting, prefs file lose "world available" mode.
I checked out P1ngu1n_'s implementation using PreferenceFragment, but it still doesn't work for me. Do any of you have an idea why?
Here is my source
The only difference I can see is that I don't have an xml file for the preferences and that I'm adding the keys in the fragment.
I even checked the permissions and they seem to be fine.
asdfasdfvful said:
I checked out P1ngu1n_'s implementation using PreferenceFragment, but it still doesn't work for me. Do any of you have an idea why?
Here is my source
The only difference I can see is that I don't have an xml file for the preferences and that I'm adding the keys in the fragment.
I even checked the permissions and they seem to be fine.
Click to expand...
Click to collapse
If the permissions seem to be fine, than what doesn't work?
P1nGu1n_ said:
If the permissions seem to be fine, than what doesn't work?
Click to expand...
Click to collapse
That's what confuses me. I have the xml file under shared_prefs and it definitely has values. However, xposed won't read it unless I open the app itself.
Sent from my Nexus 5 using Tapatalk
Hook is in PhoneWindowManager class, I need to put a value to Settings.System. ContentResolver from the available mContext variable is used.
I get the following:
Code:
InvocationTargetError: java.lang.SecurityException: Package android does not belong to 10036
10036 is UID of my module.
- Which context did you use to get content resolver?
- Depends on where your hook is.
Although your hook is in phone window manager, it still depends from where method you are hooking was called from. If it was called from different package that has different permissions (such as your module app), you will have to clear an identity of calling package while using system settings.
Something like:
Code:
long ident = Binder.clearCallingIdentity();
try {
// store to system settings or whatever
} finally {
Binder.restoreCallingIdentity(ident);
}
- Another option is to add necessary permission to your module's manifest
My module already has WRITE_SETTINGS permission. I use mContext variable that is available in PhoneWindowManager, never had a problem with it. Calling from a separate thread that is created in screenTurnedOff() method.
PhoneWindowManager has a lot of similar code involving Settings.System:
Code:
android.provider.Settings.System.putIntForUser(mContext.getContentResolver(), "screen_brightness_mode", 0, -3);
I tried ...ForUser methods with -2, -3 and 1000 UIDs - still the same error. Regular methods should use current process UID, so it's 1000 anyway.
No idea how it still knows that Xposed module is involved, code is supposed to be executed as if it's a part of a hooked app.
But I guess it knows) so clearing calling identity works perfectly, thanks.
I assume thread in screenTurnedOff you mentioned is your own you created? If yes, then for some reason thread in which runs phone window manager is thinking it's some kind of a foreign thread although created within phone window manager. Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.
C3C076 said:
Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.
Click to expand...
Click to collapse
screenTurnedOff is a stock method, it's called whenever it's called Definitely not from my module. I bet there is an explanation, something complicated)
From this day onwards, apps that Change state of SELinux are forbidden on Google Play Store. Those, who have such apps, have 14 days to fix violations or their apps will be removed.
Here's example of message from google:
This is a notification that your application, SELinux Mode Changer, with package ID com.mrbimc.selinux, is currently in violation of our developer terms.
…
REASON FOR WARNING: Violation of the dangerous products provision of the Content Policy:
“Don’t transmit or link to… items that may introduce security vulnerabilities to or harm user devices, apps, or personal data.”
After a regular review, we have determined that your app lowers a user’s device security by modifying or disabling SELinux on the device. To ensure a safe user experience for Play users, we have determined that apps with this functionality are noncompliant.
Please remove this functionality from your app within 14 days to achieve policy compliance. Once approved, your application will again be available with all installs, ratings and reviews intact.
This notification also serves as notice for other apps in your catalog. You can avoid further administrative action by immediately ensuring that no other apps in your catalog are in violation of (but not limited to) the above policy. Please also ensure your apps’ compliance with the Developer Distribution Agreement and Content Policy.
All violations are tracked. Additional suspensions of any nature may result in the termination of your developer account, and investigation and possible termination of related Google accounts. If your account is terminated, payments will cease and Google may recover the proceeds of any past sales and/or the cost of any associated fees (such as chargebacks and transaction fees) from you.
If you feel we have made this determination in error -or feel that this functionality has been misinterpreted, please submit an appeal to the Google Play policy team through this Google Play Help Center article.
The Google Play Team
New definition of "dangerous product
Google play content policy
Google play distribution agreement
What are we going to do?
I can confirm this issue as I also received this message by Google-Play some hours ago.
My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.
As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").
What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?
funtax said:
I can confirm this issue as I also received this message by Google-Play some hours ago.
My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.
As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").
What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?
Click to expand...
Click to collapse
Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.
jerryfan2000 said:
Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.
Click to expand...
Click to collapse
Might I ask you which apps and features are affected?
PhinxApps said:
Might I ask you which apps and features are affected?
Click to expand...
Click to collapse
Button Savior (root). Assistive Zoom, oneClick Scroll. In my app, I create a jar with private API invocation in it and start the jar as a shell command by exec or something that I dont quit remember.
I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?
arpruss said:
I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?
Click to expand...
Click to collapse
Hmm, the e-mail is just a warning.. I think the apps will be removed in 13 days.
The title shouldn't matter, I assume it's just a scanner/grep which they run against eg. the classes.dex and search for "setenforce".
My app doesn't use this command normally, nor is it an app which is used by the 0815-user - it cannot be a human who decides about good/bad
But does this help us in any way?
This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.
https://mega.co.nz/#!jhgA3Spb!oOS9ru9q5dDfS5V9iHLFXUTiuZVTSbNk1iyrLrq-lus
tmjm28 said:
This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.
https://mega.co.nz/#!jhgA3Spb!oOS9ru9q5dDfS5V9iHLFXUTiuZVTSbNk1iyrLrq-lus
Click to expand...
Click to collapse
Thanks for sharing!
I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.
funtax said:
Thanks for sharing!
I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.
Click to expand...
Click to collapse
... which isn't possible on bootloader locked (exploit freed) devices
Has anyone an idea how to exactly interprete this message from Google?
I assume they parse the APK for "setenforce" and blame all apps which use it.
I fully understand and confirm Google's decision, no matter that it's realy a pain in the a** for some of us.
So, what are your thoughts about the following:
1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
2. do the modifications you need to do and hope this modifications are still working after enforced-mode is active again (how would a "execmod"-exception perform if the text-relocations have been made while SELinux was off?)
3. now call setenforce again but with "1", to re-renable SELinux
In other words:
1. would SELinux recognize that a text-relocation was made while it was disabled and then activated?
2. would it be ok to temporary disable SELinux but then re-enable it shortly after the required modifications?
@Chainfire: maybe #1 is something you might know due to SuperSU?
Removed setenforce 0 and surprisingly my app is still working. Guess newer superSU can bypass selinux restriction to some level.
jerryfan2000 said:
Removed setenforce 0 and surprisingly my app is still working. Guess newer superSU can bypass selinux restriction to some level.
Click to expand...
Click to collapse
Yes, that's correct. SuperSU sets itself to "permissive" in most times afaik - so if you run your restricted commands via SuperSU, you might not get problems with SELinux.
But if another process/pid is running into issues with SELinux, that won't help you.
To anyone still having to modify the SELinux state I would advice you guys to use the Audit messages.
You might not even need to change SELinux to permissive. It's even mentioned in Chainfire's SU documentation in detail.
Catalyst06 said:
To anyone still having to modify the SELinux state I would advice you guys to use the Audit messages.
You might not even need to change SELinux to permissive. It's even mentioned in Chainfire's SU documentation in detail.
Click to expand...
Click to collapse
This might indeed help some of the devs to adjust their commands to work with SELinux enforced - good hint, pretty sure many users are not familar with that
Ohh.. I must adjust myself: I wasn't aware of the SELinux-patcher. Might be an acceptable workaround?
funtax said:
1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
Click to expand...
Click to collapse
If Google catches this, they may be more tough on you.
I got notices for 3 variants of my Spirit FM apps. Was just a debug/test menu item.
Not needed for my Spirit2 app, but the Spirit1 app did direct access to audio and other devices and won't work on Lollipop otherwise. Not a big deal for Spirit1 really though, because I will likely never release a non-beta compatible with Lollipop.
So I removed the code.
Now I have a tricky issue because I was trying to slowly roll out a new version to KitKat users. So now, 80% of my Lollipop users may still have the "bad" app and I can only fix that by increasing the KK rollout to 100%.
Wonder if Google will kick me at the 14 day mark if I don't go to 100%.
mikereidis said:
Now I have a tricky issue because I was trying to slowly roll out a new version to KitKat users. So now, 80% of my Lollipop users may still have the "bad" app and I can only fix that by increasing the KK rollout to 100%.
Wonder if Google will kick me at the 14 day mark if I don't go to 100%.
Click to expand...
Click to collapse
Any news since? It seems Google pulled the trigger...
Sine. said:
Any news since? It seems Google pulled the trigger...
Click to expand...
Click to collapse
I went to 100% with my rollout just to be on the safe side.
I have had no followup problems. My affected apps are still selling.
Would have been nice for Google to send a "Thank you for co-operating" email.
I am sorry to hear that the SCR Pro developer has had his developer account terminated.
Termination is an EXTREME measure seemingly intended for confirmed malware spreaders.
I think it is VERY rare (if not impossible) to get a terminated account re-instated. I don't recall ever hearing of a re-instatement.
All of us small developers dependent on Google Play for our income are just a few Google mouse clicks away from having our indie careers ended and Google just does not care.
Why are they doing this?
I'm not sure if this is a good decision from Google. I fully understand that this could help to protect users, but in my opinion, a warning on the device would have been enough.
Android should be an open System. A user installing a permissive kernel, or changing a existing one to permissive mode, could be expected to know what she or he is doing.
I have to recompile the kernel for my SM-P605 because it was the only way to get it to work in permissive mode. Without the ability to do the mode switching by app, I have
to do this ugly changes by hand or make them persistent. Without this I'm even not able to do a chroot and run another Linux-distro on such a device. Forcing developers
to bypass such restirctions is the bigger security issue. If I'm not able to do such things, I could just as well buy a device made by apple.
What would a normal Linux user say, if he isn't allowed to get root access or couldn't download programs which don't work on a Kernels not enforcing SELinux.
mame82 said:
I'm not sure if this is a good decision from Google.
Click to expand...
Click to collapse
Google doesn't care.
Android is now dominant, and Google is closing it off, going closed source on the increasingly important Gapps/GMS etc.
Android Auto, TV, Wear, Play, etc. etc: closed source.
DRM will come and Google doesn't want us bypassing it. We already have it in locked bootloaders for non-Nexus.
This likely makes business sense for Google. They are the new Microsoft, not quite as evil perhaps, but getting closer all the time.
Alright everyone, I'm Trailblazer101, an Android Developer who likes to take advantage of, and make better, the unique features of the phones I purchase. I started off with the Samsung Continuum back in 2010, which had a ticker ahead of its time, and went from there. I work 2 jobs, so time is tight sometimes, but I still manage to work on these things, a fun passion/hobby.
Status Updates
Code:
5/12
--- I got my patch working, and tested it out with a simple demo that takes advantage of the new capabilities. I've posted a Guide below!
5/10
--- Now that Verizon users have root, I will begin testing this myself :) Thanks to those who helped me figure out what we'd have to do, so I can get started right off the bat! I'll keep you posted.
What is this?!!
Okay, so by default the Feeds that you can make are restricted to the capabilities of a RemoteView. This severely limits what you can do with the Feed. Take a look here to see what exactly is supported, by default: http://stackoverflow.com/a/16089389
However, any Samsung App (which includes a few signed by Samsung on the Galaxy Apps Exclusives page) has the ability to put whatever it wants on the screen, just like a regular App. I've now extended that invitation on over to you/us!
Guide
The steps to take advantage of this is a little convoluted, so let me break it down for you easy!
STEP 1:
You have to flash my patch to allow this development to actually work. You can download it here: View attachment Trailblazer101_S6Edge_Advanced_Feeds_Patch.zip. Then flash it using FlashFire, or extract the zip and put everything where it needs to go, making sure to set the permissions appropriately!
STEP 2:
Now you can start developing your new Custom Feed! I would suggest using my simple demo project as your base, and going from there! You can find that here: View attachment EdgeScreen-BACKUP.zip. Extract it and take a look at the source!
STEP 3:
From here on out is where things get tricky... Without changing a thing, if you build from source and try to debug, it won't work. Why? Because the API that Samsung gives developers, like us, is different than the one they use for themselves. So Here's what you gotta do-- without changing a thing, build the Project. The best way to do that without debugging within Android Studio is to go to Gradle Projects -> :app -> Tasks -> build -> assembleDebug. This'll make the built apk and put it within "..\.EdgeScreen-BACKUP\app\build\outputs\apk\app-debug.apk".
STEP 4:
I'm assuming you have the latest Java Development Kit, and Android SDK, installed and configured properly, with their paths in the PATH variable, accordingly. You should also know how to use apktool for decompilation, at least a little I've compiled a toolkit folder based off of the test Project I shared above, which includes apktool, the NEW Samsung API files, the original built apk, and the already modified decompiled source/apk. You can download that here: View attachment Decompilation_Data.zip. Then, open a Command Prompt window and "cd" to the extracted folder.
STEP 5:
Decompile the built apk, which should be the same as the one in the extracted folder, using apktool like this:
Code:
.\apktool\apktool d -f TestFeed_orig.apk
STEP 6:
Compare the decompiled folder "TestFeed_orig" with my already modified "TestFeed_modded" one. I suggest using WinMerge! You'll see that the 'TestFeed_orig\smali\com\samsung\android\sdk' folder is very different. That's what I was talking about before, how Samsung Feeds have more options in their API. So delete the 'TestFeed_orig\smali\com\samsung' folder, and replace with the one in the '---SAMSUNG API---' folder.
STEP 7:
Continue comparing the two folders. Basically the rest of the changes are just getting our application to call the new Samsung API properly, instead of the stubs I was using in the Project. There aren't many changes you have to make, but they're all important!
STEP 8:
Once the two folders are the same, recompile it using apktool, like so:
Code:
.\apktool\apktool b TestFeed_orig
STEP 9:
Sign the new compiled apk stored in 'TestFeed_orig\dist' using your signing key. You can make your own, then use it to sign the app, following the instructions here: Official Instructions for Manual Signing.
STEP 10:
Install the newly signed apk, and enable the Feed by going to: Settings-> Edge screen -> Information stream -> Manage Feeds -> *ENABLE* FeedsCocktailExample! You may have to restart, or just hit 'reorder' in the top left. That sometimes fast-triggers it. Now turn off the screen, do the Feed Gesture to get it to turn on, and you should see our Custom Feed! It doesn't look like much, but it's using a custom view, HorizontalTextView, that would not work otherwise.
From here the options are endless. You can follow these steps and my Sample Project to play a video for a feed, if you wanted! Whatever strikes your fancy!
If you followed these steps and appreciate the help, show this thread some love, and maybe. Well i'd say buy me a beer, but it'll probably go to textbooks instead
Developer/Advanced Information!
We can make our own Feeds no problem, without root, they are just forced to use a RemoteView directly, which for all intents and purposes, is a pain in the kiester. Instead, it would be a lot nicer/convenient, without even mentioning the more advanced functionality we could bring, to use our own Views. However the version of SlookCocktailManager.UpdateCocktail that allows this is only found within a more advanced API, one I/no typical user don't have access to directly. BUT, I can still access it by decompiling for example the Edge RSS app from the Samsung AppStore, and putting/replacing the "sdk" folder from that into my own decompiled app, and recompiling. Easy enough, with apktool! (Of course with the headache of adding in my own temporary shell classes, in the project, so that I can actually write the calls, and just change the reference within the smali code once that sdk is replaced) The problem is, even when you do this, and it builds fine, installs great, and even begins initializing properly, we get an error from within CocktailBarService, the file I'm having you replace. More specifically, I tracked down the actual problem, and it comes back to "CocktailWhiteList", a class within CocktailBarServices, then checks the signature of the calling application, our Custom Feed, and sees if it comes from Samsung. This none of my expertise can fix, without being rooted, but trust me I tried. Now that we are rooted I was able to patch said apk, and get my own apps to work! Hurray!
cocktailbar service crashes when going into 'edge screen' option in settings menu.
logcat attached
Edit: sorry didn't rename cocktail bar (cocktailbarservice_signed to cocktailbarservice)
now it doesn't visibly crash, it just wont let me go into 'edge screen' option in settings menu
new log cat uploaded
This man looks promising! You have my S6 edge as soon as I have an official TWRP with working backup and restore
ktetreault14 said:
This man looks promising! You have my S6 edge as soon as I have an official TWRP with working backup and restore
Click to expand...
Click to collapse
I will help as well, when these tools are out for us..
Thanks for bringing cool stuff like this to the phone at this early date!
ktetreault14 said:
This man looks promising! You have my S6 edge as soon as I have an official TWRP with working backup and restore
Click to expand...
Click to collapse
How deep are you willing to go? Because it would be awesome if you could clear dalvik-cache, since I see this, right off the bat:
Code:
: Failed to find OatDexFile for DexFile /system/priv-app/CocktailBarService/CocktailBarService.apk ( canonical path /system/priv-app/CocktailBarService/CocktailBarService.apk) with checksum 0xfbfcb9f7 in OatFile /data/dalvik-cache/arm64/[email protected]@[email protected]@classes.dex
EDIT: could you also make sure that you set the right permissions for the apk? I'm getting the impression that they might be off with:
Code:
msg=audit(1429397519.049:355): auid=4294967295 uid=10001 gid=10001 ses=4294967295 subj=u:r:untrusted_app:s0 pid=12605 comm="ktailbarservice" reason="memory violation" sig=11
EDIT2: We might have to disable SELinux... That's rather unfortunate/puts a rather large damper on things, until custom kernels come out at least... After starting a root shell, can you try:
Code:
setenforce 0
I don't know if it'll work, but if that goes through successfully try and launch the Edge Settings Screen again!
EDIT3: Do'h. It may have been something really simple *crosses fingers* Could you please re-download the CocktailBarService, and try doing the same thing you did last time, with right permissions, and maybe a dalvik-cache wipe if it doesn't work!?
Tried the new apk you uploaded. Getting a force close still when trying to open. I changed SELINUX to permissive, wiped dalvik, even tried deleting arm64 folder as well. No luck.
04-19 00:25:09.907 E/AndroidRuntime(15867): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.samsung.android.app.cocktailbarservice/com.samsung.android.app.cocktailbarservice.settings.EdgeScreenSettingsMain}: java.lang.SecurityException: Permission Denial: get/set setting for user asks to run as user -2 but is calling from user 0; this requires android.permission.INTERACT_ACROSS_USERS_FULL
Was searching through logcat and found this. May this have something to do with the issue?
wase4711 said:
I will help as well, when these tools are out for us..
Thanks for bringing cool stuff like this to the phone at this early date!
Click to expand...
Click to collapse
Don't mean to hijack thread, but "Tool" is already available here:
NB: Chrome and IE don't translate into "Save file" - Use Mozilla which does > copy to phone and flash.
https://blck.io/twrp-2.8.6.0-zeroltetmo.img
Perfectly working on T-Mobile S6 Edge
Will
RoM_Addict said:
Don't mean to hijack thread, but "Tool" is already available here:
NB: Chrome and IE don't translate into "Save file" - Use Mozilla which does > copy to phone and flash.
https://blck.io/twrp-2.8.6.0-zeroltetmo.img
Perfectly working on T-Mobile S6 Edge
Will
Click to expand...
Click to collapse
that version doesn't work properly for me and many others; waiting for an "official" version from the TWRP folks..
trailblazer101 said:
How deep are you willing to go? Because it would be awesome if you could clear dalvik-cache, since I see this, right off the bat:
Code:
: Failed to find OatDexFile for DexFile /system/priv-app/CocktailBarService/CocktailBarService.apk ( canonical path /system/priv-app/CocktailBarService/CocktailBarService.apk) with checksum 0xfbfcb9f7 in OatFile /data/dalvik-cache/arm64/[email protected]@[email protected]@classes.dex
EDIT: could you also make sure that you set the right permissions for the apk? I'm getting the impression that they might be off with:
Code:
msg=audit(1429397519.049:355): auid=4294967295 uid=10001 gid=10001 ses=4294967295 subj=u:r:untrusted_app:s0 pid=12605 comm="ktailbarservice" reason="memory violation" sig=11
EDIT2: We might have to disable SELinux... That's rather unfortunate/puts a rather large damper on things, until custom kernels come out at least... After starting a root shell, can you try:
Code:
setenforce 0
I don't know if it'll work, but if that goes through successfully try and launch the Edge Settings Screen again!
EDIT3: Do'h. It may have been something really simple *crosses fingers* Could you please re-download the CocktailBarService, and try doing the same thing you did last time, with right permissions, and maybe a dalvik-cache wipe if it doesn't work!?
Click to expand...
Click to collapse
Hi trailblazer, I set the permissions the same as the original apk ,
right lets try again: I've downloaded the new version and set permissions, wiped dalvik-cache but when trying to disable SELinux i get
tmp-mksh: 0 : not found.
and when going into 'edge screen' settings i get unfortunsatly cocktailbar service has stopped.
Catlog attached:
I used this to modify SELINUX. For anyone else who is helping out, try this.
[4/19] QuickLaunch Demo And Advanced Feed Development Request For Rooted Users
b-reezy said:
I used this to modify SELINUX. For anyone else who is helping out, try this.
Click to expand...
Click to collapse
I sent you a PM! I explicitly declared that permission for each activity, so let's see how it goes now! I put the same apk I sent you now on the OP, so the other testers can try it! In the mean-time, I do have something real for you guys to play with! It's the QuickLaunch window, customizable and all (from hitting the Feeds Settings Icon). I'll put that in the OP with the tag "WORKS(Kinda)"!
One thing, which is a big reason why I'm trying to do it this way-- clicking the icons launches the app, it just doesn't turn the screen back on! I've tracked it down, and it seems as if when the Feed Screen is on, it has the SCover flag set to on, manually, but when a user clicks a button from another Feed, it turns that flag back off, thus turning the screen back on. The easiest/cleanest way for us to do that too would be our Custom Feed Panel implementing the same OnClickHandler that the others do, just can't without doingwhat we're trying to do!
EDIT: Please still use the QuickLaunch apk with the tag "Signed" though for testing the replacement of CocktailBarService! My new one just does it the bad way, and had to get rid of the code for trying the good.
(There's other ways to turn the screen on, but the way I'm trying to do it does it easily, and allows for more advanced functionality!)
FOR DEVELOPERS:
If you are interested in taking what I have and running with it/collaborating, I am more than willing to send all sources of what I have so far, my resources that I've been using, along with all information gathered so far. Just ask!
Hopefully this will become available for non-rooted. I am DIEING to get more functionality out of the Edge API for this phone. The feed is an awesome option, but having to swiping finger is a pain in the @$$. A double tap on the edge or an automatic turn on would be AWESOME when Texts or missed calls are there.
b-reezy said:
I used this to modify SELINUX. For anyone else who is helping out, try this.
Click to expand...
Click to collapse
BTW.. can be disabled in the kernel source also.. I did that in m8 times
trailblazer101 said:
I sent you a PM! I explicitly declared that permission for each activity, so let's see how it goes now! I put the same apk I sent you now on the OP, so the other testers can try it! In the mean-time, I do have something real for you guys to play with! It's the QuickLaunch window, customizable and all (from hitting the Feeds Settings Icon). I'll put that in the OP with the tag "WORKS(Kinda)"!
One thing, which is a big reason why I'm trying to do it this way-- clicking the icons launches the app, it just doesn't turn the screen back on! I've tracked it down, and it seems as if when the Feed Screen is on, it has the SCover flag set to on, manually, but when a user clicks a button from another Feed, it turns that flag back off, thus turning the screen back on. The easiest/cleanest way for us to do that too would be our Custom Feed Panel implementing the same OnClickHandler that the others do, just can't without doingwhat we're trying to do!
EDIT: Please still use the QuickLaunch apk with the tag "Signed" though for testing the replacement of CocktailBarService! My new one just does it the bad way, and had to get rid of the code for trying the good.
(There's other ways to turn the screen on, but the way I'm trying to do it does it easily, and allows for more advanced functionality!)
FOR DEVELOPERS:
If you are interested in taking what I have and running with it/collaborating, I am more than willing to send all sources of what I have so far, my resources that I've been using, along with all information gathered so far. Just ask!
Click to expand...
Click to collapse
Liking the Quicklaunch app , are you still needing testers? or have you got all the info you need?
Alex-V said:
BTW.. can be disabled in the kernel source also.. I did that in m8 times
Click to expand...
Click to collapse
Exactly and imo its better if its done this way..
for anyone interested
you need to edit the security/selinux/selinuxfs.c file from source
FIND:
Code:
selinux_status_update_setenforce(new_value);
#else
ADD RIGHT BELOW "#else":
Code:
new_value = 0;
So it becomes:
Code:
selinux_status_update_setenforce(new_value);
#else
new_value = 0;
or use this one (from the G925F source)
friedrich420 said:
Exactly and imo its better if its done this way..
for anyone interested
you need to edit the security/selinux/selinuxfs.c file from source
FIND:
Code:
selinux_status_update_setenforce(new_value);
#else
ADD RIGHT BELOW "#else":
Code:
new_value = 0;
So it becomes:
Code:
selinux_status_update_setenforce(new_value);
#else
new_value = 0;
or use this one (from the G925F source)
Click to expand...
Click to collapse
yeah.. that's the one I used.. I'm still for and back to root or not..means for me.. develop roms and kernels ..or use it as it is.. lol..
friedrich420 said:
Exactly and imo its better if its done this way..
for anyone interested
you need to edit the security/selinux/selinuxfs.c file from source
FIND:
Code:
selinux_status_update_setenforce(new_value);
#else
ADD RIGHT BELOW "#else":
Code:
new_value = 0;
So it becomes:
Code:
selinux_status_update_setenforce(new_value);
#else
new_value = 0;
or use this one (from the G925F source)
Click to expand...
Click to collapse
Hii my friend, i also still , have a non rooted S6 Edge :thumbup:
Hey guys, I finished the QuickLaunch Feed and posted it in the Apps Folder here:
Click Me!
I did manage to get it to turn the screen on, then, with the clicking of the shortcuts, and it still launches it once unlocked (if you have a lockscreen). I am going to begin work on a music player Feed, now
I will continue development on more advanced Feeds, and also delve into enhancing the edge in other ways, once we Verizon users get root (or until I win the lottery and get a Sprint version ). I see all these great opportunities to make it better, I just can't do anything with it until I'm rooted, since this didn't go as well as I planned. Where we are stuck at now is this, and where it would be too much of a pain for me to do without a phone of my own to test one:
We need to re-sign the system with a signature key we have access to. This includes framework, apps, and the priv-apps signed with the samsung key. Then I can go about doing what I wanted to do, but otherwise, it's a no go.
A developer who does have a Sprint or T-Mobile version with root, I can tell you the information I gathered so far. I have seen where the 'turn screen on gesture' is stored, and all these other great things, I just can't right now
trailblazer101 said:
Hey guys, I finished the QuickLaunch Feed and posted it in the Apps Folder here:
Click Me!
I did manage to get it to turn the screen on, then, with the clicking of the shortcuts, and it still launches it once unlocked (if you have a lockscreen). I am going to begin work on a music player Feed, now
I will continue development on more advanced Feeds, and also delve into enhancing the edge in other ways, once we Verizon users get root (or until I win the lottery and get a Sprint version ). I see all these great opportunities to make it better, I just can't do anything with it until I'm rooted, since this didn't go as well as I planned. Where we are stuck at now is this, and where it would be too much of a pain for me to do without a phone of my own to test one:
We need to re-sign the system with a signature key we have access to. This includes framework, apps, and the priv-apps signed with the samsung key. Then I can go about doing what I wanted to do, but otherwise, it's a no go.
A developer who does have a Sprint or T-Mobile version with root, I can tell you the information I gathered so far. I have seen where the 'turn screen on gesture' is stored, and all these other great things, I just can't right now
Click to expand...
Click to collapse
very nice.. thanks my friend ?
This is just sounding AWESOME! I am on AT&T so will have to wait as well for Root. I was wondering if there is a possability for the edge to just turn on, on its own without the need to swipe the screen? Like when a new notification comes in it will just scroll across the edge (or maybe the icon will blink on and off until you see it and swipe).
I still feel the swipe is to hard to do consistantly and would rather use a double tap or something if the auto on isn't possible.
Method to hide "My Fire"/kindle name in statusbar? Root/xposed OK, but keep fireOS
The xposed module GravityBox LP works well for modifying a lot of statusbar elements, but the "My Fire" (or "John's Fire, etc etc) text is FireOS specific, and I haven't found a way to remove it. Any suggestions hugely appreciated!
@trclocke
not exactly same what you want, but give them a chance
Device options - Change your device name
type something like "-" (w/o quotes), " " spaces not working
Kramar111 said:
@trclocke
not exactly same what you want, but give them a chance
Device options - Change your device name
type something like "-" (w/o quotes), " " spaces not working
Click to expand...
Click to collapse
Right, but this requires you to keep the device registered to your amazon account, which causes other issues (namely automatic amazon app store updates where it'll flag some play store apps as "sideloaded" and prompt you every day to update them). I did a · for a while, but the pushed updates got super annoying, and GravityBox LP doesn't seem to recognize it to hide manually.
Plus a · still looks out of place, I'd prefer entirely blank I'll treat this as a bump as well as a reply I guess and hope someone else has an idea.
trclocke said:
Right, but this requires you to keep the device registered to your amazon account, which causes other issues (namely automatic amazon app store updates where it'll flag some play store apps as "sideloaded" and prompt you every day to update them). I did a · for a while, but the pushed updates got super annoying, and GravityBox LP doesn't seem to recognize it to hide manually.
Plus a · still looks out of place, I'd prefer entirely blank I'll treat this as a bump as well as a reply I guess and hope someone else has an idea.
Click to expand...
Click to collapse
Believe you can block Amazon app store updates by killing the underlying service and modifying receivers to keep it from restarting (or try hibernating with Greenify). FireOS Skin tweaks prevent most GB status bar controls from working as designed.