yashsingh1/xdaforums huggingface dataset:
[G 2014 Q&A, Help & Troubleshooting] hatimc:
HELLO GEEKS :p

I AM +HATIMCHATHIWALA ABOUT TO GUIDE YOU FOR THE XT1063 FREEZING PROBLEM IN CYANOGEN MOD

PROBLEM OF FREEZING XT1063 IN BOOT

PROBLEMS OCCURS DUE TO SEVERAL ROMS LIKE CYANOGENMOD NIGHTLY

TRY TAKING OUT THE BATTERY IN CASE OF FREEZING XT1063

KEEP PRESSING THE LOW VOLUME(-) BUTTON AND PLUG IN TO CHARGE OR POWER SOURCE

PRESSING THE TWO VOLUME UP AN DOWN KEYS TRY CONNECTING TO POWER SOURCE

AFTER GETTING INTO RECOVERY INSTALL A STABLE ROM OR SIDELOAD IN CASE OF SOFT BRICKING

BUT AS THE FREEZING CONTINUES...... CONTACT ME. FOR NOW PRESS THE THANKS BUTTON:good:
[G 2014 Q&A, Help & Troubleshooting] Razvan:
Hi there,

Please wait until mods will move this thread to the device specific forum.

Stand by
[Nexus 6 Q&A, Help & Troubleshooting] EvanVanVan:
Should I bother upgrading from LMY47D to LMY47E? Was anything important changed, or are there any problems with LMY47D? I'm stock rooted (and unlocked obviously).
[Nexus 6 Q&A, Help & Troubleshooting] DebianDog:
Small camera change and the radio but no nothing major.

Sent from my Google N6 on VZ
[Nexus 6 Q&A, Help & Troubleshooting] cam30era:
[MENTION=1861966]EvanVanVan[/MENTION],

Depends on what network you're on. If VZW then definitely yes. If TMO, you should be on "M". Anyone else, " D" appears to work as well as anything else.
[Nexus 6 Q&A, Help & Troubleshooting] EvanVanVan:
Hmm, ok... I'm on VZW but bought it from Motorola...So that's still a yes? May I ask why "definitely"?
[Nexus 6 Q&A, Help & Troubleshooting] cam30era:
VZW branded phones are shipping with E. And several users have reported that VOLTE works for them on E, but not D or M.
[Nexus 6 Q&A, Help & Troubleshooting] EvanVanVan:
Oh, nice yeah I haven't been able to get VoLTE activated on my line. I will definitely try upgrading right now.

Thanks man
[Nexus 6 Q&A, Help & Troubleshooting] DebianDog:
It would have helped if you said you were on Verizon first[emoji106]

Sent from my Google N6 on VZ
[Nexus 6 Q&A, Help & Troubleshooting] EvanVanVan:
You're right, and I actually had it in there when I first wrote it, but I thought it got kinda confusing and wordy...and didn't honestly think it would matter since they're all the same phone (at least the non verizon ones).

Thanks for the help though.
[Nexus 6 Q&A, Help & Troubleshooting] GrillMouster:
VoLTE/Advanced Calling is working fine on my Nexus 6 running LMY47D with Verizon. I purchased my Nexus 6 from Motorola months ago and updated to 5.1 LMY47D as soon as it was available. I used the instructions found at Droid Life and activated Advanced Calling through my Verizon Wireless account on their website.
[Nexus 6 Q&A, Help & Troubleshooting] Gage_Hero:
Didn't flash boot loader from 47D to 47E fats boot

I side loaded 47D then unlocked the boot loader and fastboot flashed everything but boot loader and user data, my question is should I go a head and flash the bootloader from 47E? Will it make any difference and if I do will it cause any problems like erase data or anything like that?
[Nexus 6 Q&A, Help & Troubleshooting] DebianDog:
From my understanding if you are on any version 5 .1 bootloader you are fine there's no difference. but you can't go back to 5 .0 without loading a 5.0 bootloader

Sent from my Google N6 on VZ
[Galaxy S 5 Q&A, Help & Troubleshooting] trainspotter375:
Hi Guys, new to this forum so plz be gentle. Been reading this forum for a while now so hoping you guys and girls with expert knowledge can advise me if there is a work around or root i could download. Anyway, heres the problem, have a pioneer avh-x3600dab hu in the motor with the additional pioneer CD-ML100 smartphone interface and been using the samsung galaxy S3 with it with the drivelink app, i know the drivelink app has connection problems but it was okay as all i really wanted to use was the google map app on the hu. Well having updated to the samsung S5 i eagerly awaited the lollipop update but when i connect the S5 it comes back with a connection error even though the s5 says mirrorlink connected. Pioneer say cos the hu is running 1.0 mirrorlink and the s5 uses 1.1 then tough, pioneer cant or wont be updating the mirrorlink. Is there anyway i can get the drivelink app running on the s5 or is there another way to miiror the s5 screen on the hu. Thanks guys in advance:laugh:
[Galaxy S 5 Q&A, Help & Troubleshooting] gulatalisa:
The same problem here. Pioneer's support told me there is no way to do work in S5 because of the mirrorlink 1.1... I tried ARU, ARL, and nothing... after 2 months I give up. But my model is avh-x2780bt...
[Android Software Development] Lanchon:
DEPRECATED: Workflow Automation Scripts HOW-TO

DEPRECATED: Workflow Automation Scripts HOW-TO

These scripts bundle several tools (including DexPatcher) and automate boilerplate actions that are part of a typical workflow. They are available only for Linux. Take the leap today, get yourself free, get Linux Mint Cinnamon 64-bit.

Installation

# cd to a suitable install dir such as '~/opt' or '~/android/tools'.

git clone [url]https://github.com/Lanchon/DexPatcher-scripts.git[/url] dexpatcher
cd dexpatcher
chmod +x dxp-*

# edit 'dxp.config':
# -set the path to android sdk (defaults to '~/android/sdk').
# -disable bundled tools to use the ones in $PATH if desired.

# add 'dxp-*' scripts to $PATH:
# -symlink the 'dxp-*' scripts in a suitable dir in the $PATH such as '~/bin'.
# -or add the 'dexpatcher' dir to $PATH.

Sample Workflow

# cd to a suitable workspace dir.

dxp-setup-for-apk path/to/TheApk.apk
cd TheApk
dxp-create-keystore

# in 'src-cfr' you will find decompilation of the app to Java (with errors).
# you can use these files to plan your changes.

# in 'src-cfr-nocode' you will find decompilation of empty method stubs.
# you can use selected files as a basis for your patch.

# create your patch as Java files in 'src'.
# the symbols of the original app will be accessible to your patch code.

dxp-make
adb install -r patched.apk
[Android Software Development] Lanchon:
The Big TO-DO List

The Big TO-DO List

...of things I would like done in this project, but that I will probably not have the time to implement myself.

DexPatcher-tool

Moved here: https://github.com/Lanchon/DexPatcher-tool/issues

DexPatcher-gadle

Moved here: https://github.com/Lanchon/DexPatcher-gradle/issues

DexPatcher and javac

Modify javac so that all source symbols -even those defined inside edited classes- are available during compilation. This could produce a patched javac executable, or the standard javac could be patched in-memory using java agents, or its in-memory data structures hacked from an annotation processor (a la Project Lombok).

Decide if dex2jar and jar2dex/dx are transparent and mature enough to move DexPatcher 2.0 to the java bytecode realm, and stop operating at the dalvik bytecode level. [UPDATE: It is not.] Or a VM abstraction could be implemented as a backend to DexPatcher so that the same font end could be used for both dex and class files.

If the project is moved to the java bytecode realm, decide if the new DexPatcher should be a standalone tool like it is today, or a java agent/annotation processor that modifies javac to do the patching during compile time. This would make the tool very easy to integrate into most build systems.
[Android Software Development] Lanchon:
just added the documentation section
[Android Software Development] pyler:
I checked docs and wow, massive :) Maybe you can make some easier examples how to use it (some small patches).
[Android Software Development] Lanchon:
there is a lot of docs missing, especially regarding the workflow, how to extract and use symbols from the source apk, etc. for now im working on 0.2 :)
[Android Software Development] Lanchon:
UPDATE: version 0.2.0 released!
[Android Software Development] Lanchon:
UPDATE: version 0.3.0 released!
[Android Software Development] PerfectSlayer:
Looks good ;)

I will look at it more deeply when I found time.

I'm surprised there isn't so much feedback… May be could you add some examples / details in the OP?
[Android Software Development] Lanchon:
i still need to evolve the tool a little with respect to handling of fields, and then it's mostly done. but i need to document a full workflow, including obtaining symbols against which to build the patch (you want your patch code to be able to use all of the source app's code).
[Android Software Development] agentdr8:
Very interested in seeing how this tool progresses. :good:
[Android Software Development] laura almeida:
I still have no idea how to use this tool
[Android Software Development] Lanchon:
UPDATE: version 0.4.0 released!
[Android Software Development] Lanchon:
take a look a the test run and samples. docs are very incomplete, but i guess you should understand them if you have experience patching apks in smali.
[Android Software Development] PerfectSlayer:
Don't worry for breaking patches.. Focus on making the better API / usage you can while you are in development. We will thanks you later ;)
[Android Software Development] Lanchon:
UPDATE: version 1.0.0-beta1 released!

An explanation of the workflow and some helper scripts should follow soon.
[Android Software Development] Lanchon:
UPDATE: added Workflow Automation Scripts and HOW-TO
[Android Software Development] PerfectSlayer:
Tips: you could use the 2nd argument of git clone instead of running mv command ;)
[Android Software Development] pdaaalex:
The speed of development is atonishing... :eek:

Keep up the good work!
[Android Software Development] Lanchon:
UPDATE: DexPatcher featured on XDA portal !

includes full sample, please see the OP for details.
[Android Software Development] Lanchon:
UPDATE: added the 'patched-dex' sample

this sample sidesteps the android build system completely and only patches dex code (an Android framework file in this case) without dealing with resources, manifests, etc. a plugin set for this kind of workflow would probably be justified, but for now this sample is based on an ad-hoc Gradle build script. as always, a correctly configured local.properties file is needed in the project root dir.

The sample is here: https://github.com/DexPatcher/dexpatcher-gradle-samples/tree/master/patched-dex

ATT: [MENTION=1844875]CosmicDan[/MENTION]
[Android Software Development] cryptyk:
Hi,

I have a couple of basic questions and hoping the answers are pretty straight forward so I can decide whether to go deeper.

I'm the author of a modestly successful Xposed module called Amplify. I'd like to move away from Xposed as a requirement and it sounds like DexPatcher might be the right way to do so. Just want to make sure I understand what's possible before I dive deep.

Some questions:

- Can I patch system functions (e.g. PowerManager when apps try to acquire wakelocks)?

- Does the signature validation mess that up? Assume that the user has root. Would I also just patch the system signature verifier?

- How do I handle different Android versions, roms, etc?

- What does installation look like for the user? They install the app from the app store, then what? The app applies the scripts, then I reboot the device?

- Any other big watch-outs as you move from Xposed to DexPatcher?

Thanks!

Ryan
[Android Software Development] kanlo:
Hi Lanchon,

setting multiDex to true was the solution. Thank you very much. Dexpatcher is amazing :good:

Kind regards
[Android Software Development] Lanchon:
lol ok, i assume you changed the apk of the 'patched-app' sample but kept on using its skeleton.

ok, then all is good, you dropped in a multidex app and so you just needed to enable multidex support.

thanks!
[Android Software Development] cryptyk:
Wow, thank you for the detailed reply! I have a way better sense for what's possible today, the overall power of what's possible in the future, and what the challenges are. As an app developer who also has a full-time job, I know what you mean about having vision, but not enough time :)

It sounds like DXP isn't the right path, but since you know a LOT about how the underlying system works, let me ask: If I've already written an Xposed module that hooks some methods in the system process and I want to remove the requirement for my users to have Xposed installed, what options do I have?

Ideally there would be a re-distributable, self-contained library that developers could include in their projects to get the same behaviors of hooking/patching other apps with the only requirement being a rooted device. It sounds like there's no such thing, but as a dev, that's what I would wish for :) The requirement to have users install xposed/magisk is painful for a lot of people.

Thanks again for your time!
[Android Software Development] Lanchon:
xposed is the route today. instead of apps patching code by themselves, i like having a centralized control center that i trust. ideally app patches shouldnt be root and would not have more rights than the patched app, but that's not true of xposed, unfortunately.

installing xposed is fairly simple, and it gives great service for devs such as yourself. if you took over xposed and rolled your own patcher inside your app, imagine the huge issues u'd have with all sort of phones and the support you'd need to give! you dont want that. not to mention, what would be the interaction between different patchers in a system? :)

thanks!
[Android Software Development] cryptyk:
Roger. Sounds like that's just the state of affairs today. I look forward to a future where something a little more secure like dxp-live is in place :)

Enjoy your weekend!

Ryan
[Android Software Development] CosmicDan:
I know how to make apps fairly well and also have admin rights to a reliable dedicated server that can be used for hosting some kind of repository, so I'd love to be notified and possibly help if you ever decide to take another look at this ;)
[Android Software Development] Lanchon:
thanks :) ill keep it in mind!

did you try the sample i added for you? i think it's what you needed
[Android Software Development] CosmicDan:
First I got a weird error about constructor ambiguity with lines 75 and 76 in build.gradle, so I explicitly cast the first arg to String, and opened fine.

I then had to manually refresh the gradle project, and running dexpatcher produced a patch and patched dex that indeed matches expected results.

Was there supposed to be a way to browse the source dex code/signatures i.e. service.jar (like with the other samples) though? Or is that part of the plugin? Not a big deal if so, there are many ways to view decompiled sources/signatures.

EDIT: I see the "importSourceSymbols" thing in build.gradle, so this suggests to me that it should indeed be showing the source jar in libraries...
[Android Software Development] Lanchon:
> First I got a weird error about constructor ambiguity with lines 75 and 76 in build.gradle, so I explicitly cast the first arg to String, and opened fine.

hmmm... i wish you could post the exact error. i can't reproduce it of course, which is puzzling because groovy is part of the gradle distro, so we should have the same. have you upgraded the gradle wrapper for this project? are you using the wrapper? could you run "./gradlew build" from the command line? i'd like to repro and understand the problem instead of just putting the casts there blindly.

> Was there supposed to be a way to browse the source dex

good catch! i just tested, i'm being too clever in the way i inject the symbols. gradle's javac task sees them, but IDEA doesn't at all: it doesn't show them in the browser as you noted, and it also doesn't import them into the intellitype system. i have to fix this.
[Android Software Development] Lanchon:
hi,

> Caused by: D:\Android studioProjects\dexpatcher-gradle-samples-master\patched-app\patched\build\intermediates\exploded-aar\patched-app\source\unspecified\res\drawable-v21\$avd_hide_password__0.xml: Error: '$' is not a valid file-based resource name character: File-based resource names must contain only lowercase a-z, 0-9, or underscore

>	at com.android.ide.common.res2.MergingException.throwIfNonEmpty(MergingException.java:152)

in your apk, in the res/drawable-v21 directory there are several resource files named with a starting '$', and this is supposedly illegal. how they ended up there i don't know.

at first i thought it came from an older android build system that doesn't check the condition, and was going to suggest you try older android plugins. you can try all the way back to 1.5.0.

but then i found this:

https://github.com/iBotPeaches/Apktool/issues/1520#issuecomment-312359148

meaning it might be caused by using aapt2 in the original app. you can try enabling it in the 'patched' project by setting 'android.enableAapt2=true' in your 'gradle.properties' file and restarting the Gradle daemon by running './gradlew --stop' from the command line. i don't think it'll work, but worth taking a shot.
[Android Software Development] Lanchon:
i fixed the source symbols visibility, but i realized that the same problem stands for the android API boot classpath (if enabled).

i'll take a look into this other issue now.

EDIT: i added an ugly hack to make the Android API visible (but couldn't remove the JDK). i couldn't find a better way to do this.
[Android Software Development] Lanchon:
Viewing the code of the APK/DEX being patched as decompiled Java

when using DexPatcher Gradle plugins in Android Studio or IntelliJ IDEA, if you keep the importSymbols = true setting (as per defaults), then you will be able to browse just-in-time decompilation of APK/DEX classes by either of these methods:

- in the source code of the patch, position the cursor over the name of an APK class and type CTRL-B to go to its definition.

- in the 'project' pane at the bottom you will find an 'External Libraries' section, and within it there will be a 'classes.jar' that contains all APK classes.

the IDE uses the FernFlower decompiler to do JIT decompilation. FernFlower sometimes cannot decompile classes; the CFR decompiler is much better in that regard. you can use CFR instead of FernFlower by installing this IDE plugin.

thanks!
[Android Software Development] bigsupersquid:
That's lovely information. Thanks!

While I'm posting anyway, I've got a possibly stupid question, but hey, that only stops me when I already know better.

I have an obfuscated ice cream sandwich rom that I'd really like to pick certain functionality out of without having to shim ancient stock functions. Specifically, the camera app and libraries do secret things with talking to the kernel, a little differently than anything else in the rom does. I could get in there and RE the data flow and addressing and stuff by making the kernel really talkative, but I'd like to have some code outlines from the camera apk and anything related I can pick out of the framework as well, if I can get those.

I'm not wanting to adapt the apk itself to modern android... But your mention of the decompiler plugins (I've messed with both decompilers by themselves with limited success a few years back) made this question surface in my mind again.

After all the long winded explanation, the 50 dollar question:

Will I run into any obvious issues picking apart ICS with this nifty toolkit of yours, considering how out of date the android version is?
[Android Software Development] CosmicDan:
What nifty toolkit?

You'd be better off with a dedicated decompiling tool for this, DexPatcher doesn't do anything special in this regard. The built-in IDEA decompiler(s) are bare bones and fragile. I'd start with something like http://bytecodeviewer.com for serious reverse engineering. Another alternative is to convert via dex2jar and use one of the many other Java decompilers out there, some even commercial. I've had great success with procyon decompiler which is free. As for commercial ones, nothing beats JEB. It never fails decompiling in my experience, but will create Java-psuedo code that won't recompile instead - yet is relatively easy to understand (much easier than smali anyway).
[Android Software Development] Lanchon:
to analyze the camera apk or parts of the framework i would recommend:

- use dex2jar to convert them to jars,

- then use the enigma GUI to analyze the jars.

old enigma can be found here:

http://www.cuchazinteractive.com/enigma/versions.php

and this is a forked and supposedly improved enigma:

https://bitbucket.org/Earthcomputer/enigma

thanks!
[Android Software Development] Lanchon:
yes, bytecode-viewer and helios are options too, but enigma lets you rename identifiers as you go.

and there are a couple of free, closed source, online decompilers which i never tried.
[Android Software Development] bigsupersquid:
[MENTION=1844875]CosmicDan[/MENTION] too

Thanks for the suggestions. I will take a pass at looking at all of that, I've used some but not all previously even though it's been a little while.

I've had decent results from one of those online decompilers but it can't handle bigger files (decompiling shared libraries, .so, for c pseudocode.) My old RE experience was assembly on the 6809E picking apart BASIC for sound register access. 32K of code, even early 16 bit assembly, is a lot less to go through than even one apk these days.

The thing I like best about what I've read here is getting some of the symbols relabelled, and being able to inject new functionality. Earlier experiences with trying to decompile this stuff makes me tempted to try a different tack. Modify the kernel camera drivers and the camera apk to heavily log all communication between the two so I can figure out what the apk is telling the kernel, to make it turn on the third camera and access its streaming buffer on my evo 3d.

I do so detest proprietary closed source locks on hardware that has been abandoned by the manufacturer. It's bad enough while they're still selling and updating, you'd think that they'd release source after they officially stop supporting. In this case it's issues with Qualcomm and HTC abandoning perfectly functional hardware but refusing to release enough source to really make it go.

//end rant

Sorry about the rant, meant to be explanatory and I'm probably preaching to the choir anyway.

Regardless, I appreciate the suggestions and software references, and thanks again. I can only hit the thanks button once.
[Android Software Development] CosmicDan:
Heh, I remember when Chuchaz wrote enigma for the M3L project. It is a good tool for deobfuscation mappings, so yeah - it might be a good tool for this case.
[Android Software Development] Lanchon:
vote with your dollars: don't buy from HTC again then.

OEMs license technology that they can't open source if they wanted, and in the US there are laws that limit what they can be open about anyway (see: software-defined radio). but some OEMs tend to do a better job at providing enough info for devs to reuse their blobs. one such case has been oneplus, with their handling of proprietary dash charge for example.
[Android Software Development] bigsupersquid:
I'd have to avoid anything Qualcomm, they've obsoleted every SoC I've owned of theirs. At least I only buy used devices since I bought a new LG in 2009.

Htc at least releases kernel source... Unlike many others.

I'd love to have a mostly open source device, but they're ventrally more costly than I like.

I satisfy myself by making the old abandoned hardware work long past its manufacturer life expectancy, which is what the project I was asking about is for. My evo at least boots nougat, but was released with gingerbread and was updated to the ics rom I'm picking at.
[Android Software Development] CosmicDan:
Obsolescence, planned or otherwise, isn't something you can completely avoid though. Save up for a Nexus or Pixel if you want something to be supported for years.

If you want to stay up to date with the modern and ever-changing post-information age we live in though it just makes sense that you need to update your own stuff every once in a while. It's just the growing demands of human kind and society.

Surprisingly I've found Xiaomi to be the best with keeping their devices up to date fast and for the longest time, and value for money, but if you care about privacy and are more of the isolationist sort then you wouldn't be interested. Lots of anonymous telemetry in their firmware.

But this is off topic...